 TechNet Magazine October 2007

TechNet Magazine October 2007

Эффективное и ответственное использование вычислительных систем: Создание экологичного центра обработки данных

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

Dave Ohara Администрирование в Windows: Руководство по репликации Active Directory

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

Laura E. Hunter Системный центр : Новые средства управления обновлением программного обеспечения

В System Center Configuration Manager 2007 вы найдете совершенно новый механизм управления обновлениями, обеспечивающий лучшую совместимость и применимость для всех клиентов. Здесь вы узнаете, как этот усовершенствованный подход может помочь вам обновить все свои компьютеры.

Steve Rachui Связь: Пограничные транспортные серверы Exchange в корпорации Майкрософт

Каким образом Майкрософт обеспечивает доставку сотрудникам надежных сообщений, не допуская проникновения в среду обмена сообщениями потока вредоносного содержимого? Один из способов заключается в развертывании пограничных транспортных серверов Exchange Server 2007 и приложения Forefront Security для Exchange Server. Познакомимся с тем, как с помощью этих технологий можно обеспечить безопасность предприятия.

Kay Unkroth SQL Server: Оптимизация производительности ЦП SQL Server

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

Zach Nichter От редактора: Лучшее — впереди

Joshua Hoffman Инструментарий: Новые продукты для специалистов по информационным технологиям

Greg Steen Вопросы и ответы по SQL: Триггеры, срабатывающие при входе в систему, средства дефрагментации файлов данных и другое

Edited by Nancy Michell Обзор служебных программ: Virtual Machine Remote Control Plus

Matthijs ten Seldam Бизнес информационных технологий: Расчет ценности информационно-технической инфраструктуры в правительстве

Acer Maamoun Кабельщик: Протокол IP с проверкой подлинности

Joseph Davies Windows PowerShell: Работаем без сценария

Don Jones Эй, сценарист!: Да будет Silverlight!

The Microsoft Scripting Guys На страже безопасности: BitLocker и сложности доверия

Justin Troutman Материалы о рабочей среде: Руководство квалифицированного пользователя по WIM и ImageX

Wes Miller Заметки разъездного инженера: Повторное использование компьютера

Jim Lynch Конфиденциальные сведения о Windows: Вызывая доктора Ватсона

Raymond Chen


 Эффективное и ответственное использование вычислительных систем: Создание экологичного центра обработки данных
Эффективное и ответственное использование вычислительных систем За плечами Дейва Охара (Dave Ohara)

Создание экологичного центра обработки данных
Краткий обзор:
  • Системы текущего контроля использования энергии
  • Основные характеристики экологичного центра обработки данных
  • Влияние законопроекта H.R. 5646
  • Оптимальные методики для начального этапа

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

Учет потребления энергии
Одной из серьезнейших задач, с которой я столкнулся при работе над этой темой, оказалась задача осмысления обширного разнообразия цифр, предоставляемых различными источниками. В некоторых исследованиях утверждается, что на центры обработки данных приходится от 1,2 до 2,0 процентов электроэнергии, потребляемой в Соединенных Штатах. По некоторым оценкам, если бы центры обработки данных рассматривались как отдельная отрасль, то такие центры в США вошли бы в первую пятерку отраслей с точки зрения использования энергии. Между тем в США до 15-20 процентов эксплуатационных затрат центра обработки данных предприятия приходится на электроэнергию.
В исследовании, проведенном Национальными лабораториями Лоуренса в Беркли для Американского совета по рациональному использованию энергии, было выяснено, что некоторые центры обработки данных в 40 раз превышают энергоемкость обычных офисных зданий. В данном исследовании подробно обсуждаются возможности повышения энергетической эффективности с точки зрения технических средств (см. eetd.lbl.gov/emills/PUBS/PDF/ACEEE-datacenters.pdf). Имеет смысл начать с определения того, в какой степени ваш центр обработки данных использует оптимальные методики, изложенные в этом исследовании.
Без сомнения, существует множество точек зрения, исследований и цифр, относящихся к энергопотреблению. Однако в том, что энергия используется расточительно, разногласий нет. Просто представьте, какое множество серверов было приобретено с намерением получить максимум — т.е. купить настолько мощный центральный процессор, емкую оперативную память и запоминающее устройство и резервные источники питания, насколько позволяют бюджетные рамки. В последние 3-5 лет множество этих серверов эксплуатируются в среднем на 10-15 процентов. Хотя основное внимание уделяется центральным процессорам, в этом вопросе играют важную роль другие компоненты — память, диски и сетевые интерфейсы забирают значительную часть мощности и, в целом, их энергопотребление превышает потребление энергии центральным процессором.
Тем временем чрезмерная мощность оборудования (во всем — от процессоров до резервных источников питания) приводит к существенным избыточным затратам. При стремлении в большинстве отделов ИТ к снижению возможных рисков избыточная мощность является нормой. Самым надежным является решение, при котором обеспечивается избыточная мощность оборудования, даже если оно не будет оптимальным с финансовой точки зрения. Но, хотя энергия является решающим фактором, им обычно пренебрегают при вычислении затрат на обеспечение эксплуатационного цикла. К несчастью, отсутствуют стимулы для приобретения эффективных решений, и для тех, кто делает выбор, не существует финансовых льгот по результатам развертывания решения.
Однако существует промежуточное решение. Маятник отклоняется в другую сторону, когда руководство осознает, какая незначительная часть возможностей центра обработки данных используется в действительности, и рассматривает консолидацию серверов как способ снижения затрат. Гораздо проще заранее оценить необходимость в серверах, чем пытаться консолидировать их после того, как они развернуты.
С достижением отраслью ИТ нового уровня развития приоритетной становится задача оптимизации посредством снижения затрат. Потребление энергии является одним из показателей, которым руководство может пользоваться для измерения эффективности решений принятых относительно цикла эксплуатации аппаратного оборудования ИТ. AMD, Intel и изготовители серверов и других компьютерных компонентов — все они сообщают производительность своих платформ, приходящуюся на один ватт. Цифры, выражающие производительность на один ватт, можно использовать для расчета эксплуатационных затрат, применяя обратную формулу: число ватт на единицу производительности. С учетом людских ресурсов, вовлеченных в разработку решений ИТ, — сотрудников технических отделов, отделов по разработке приложений, архитектурных, эксплуатационных и производственных отделов, показатель, выражающий производительность на один ватт, дает ответ на вопрос «что будет получено взамен», и это дает возможность сравнить решения в терминах энергетической эффективности.
Почему повсеместно игнорируют энергетические затраты и пренебрегают решениями, оказывающими влияние на эксплуатационные затраты и затраты на ресурсы? Много ли вы видели центров обработки данных, работающих на полную мощность благодаря ограничениям на потребление мощности и применение охлаждения? Были времена, когда наличие достаточного физического пространства для центра обработки данных представляло проблему. Сегодня, однако, проблемой является наличие возможностей, достаточных для подачи питания и охлаждения всего имеющегося оборудования и то, как скоро эти возможности будет исчерпаны.

Важность систем текущего контроля использования энергии
Точные измерения энергопотребления выполнить трудно. Как упоминалось ранее, большинство компаний предпочитает учитывать энергетические затраты по предприятию в целом, а не анализировать потребление энергии конкретными подразделениями. Такой метод подхода к энергии как общим накладным расходам создает впечатление, что энергетические затраты не поддаются управлению в рамках подразделения. Однако это неверно.
Центр обработки данных может использовать в десятки раз больше энергии на квадратный метр, чем обычное офисное помещение, и, следовательно, даже незначительное повышение эффективности в центрах обработки данных может привести к значительной экономии. Не удивительно, что снижение затрат является основной причиной внедрения программ экономии энергии в центрах обработки данных. Проблема состоит в том, что метод минимизации затрат используется обычно для оплаты за потребление энергии, и ежемесячные затраты на ресурсы, необходимые для эксплуатации центра обработки данных, представляются одной цифрой. Затем затраты разносятся по группам исходя из занимаемого ими пространства и/или порта связи — такой подход обеспечивает далеко не точный анализ реальных затрат, необходимых для эксплуатации конкретного оборудования центра обработки данных.
В организациях редко устанавливается решение для измерения реального уровня потребления энергии конкретными устройствами центра обработки данных — главным образом из-за того, что установка системы измерения и учета потребления энергии требует значительных первоначальных вложений. Однако вложение средств в такую систему может привести к дальнейшему снижению затрат.
Конечно, сама по себе система текущего контроля потребления энергии не решит задачу — потребуется разработать план использования собранных данных для улучшения управления потреблением энергии и, в конечном итоге, добиться рентабельности капиталовложений. Обратимся к опыту канадской компании Abitibi Consolidated, крупнейшего мирового производителя газетной и бумажной продукции. В 2001 г., когда было прекращено регулирование рынка электроэнергии в Онтарио, компания Abitibi Consolidated испытала влияние колебаний цен и доступности электроэнергии. Для оптимизации своих закупок электроэнергии компания внедрила систему текущего контроля и измерений. Новая система окупилась в течение нескольких месяцев благодаря 1 проценту экономии, достигнутому компанией всего лишь вследствие более эффективных закупок электроэнергии.
Какое количество электроэнергии необходимо сэкономить, чтобы оправдать модернизацию текущего контроля энергопотребления в вашем центре обработки данных? Бил Лэинг (Bill Laing), главный управляющий по разработке Windows Server® 2008 в корпорации Майкрософт, сказал в недавнем интервью, что новый выпуск Windows Server при использовании режима энергосбережения по умолчанию позволит снизить потребление на 20 процентов, что является значительной экономией. (На рис. 1 показаны некоторые параметры электропитания, доступные в версии бета 3 платформы Windows Server 2008.) Отметим, однако, что экономию невозможно рассчитать в виде непосредственного снижения затрат на энергопотребление. Экономия определяется целым рядом других факторов, таких как стоимость создания нового центра обработки данных и ряда других систем, которые в текущее время поддерживают менее эффективные конфигурации.
Рис. 1 Параметры электропитания в версии бета 3 платформы Windows Server 2008
Рис. 1 Параметры электропитания в версии бета 3 платформы Windows Server 2008
Уже сейчас в Windows Server 2003 с пакетом обновления 1 (SP1) имеется возможность выбрать параметр «Серверная балансировка питания процессора и его производительности». Но без установки измерительной системы вам не удастся получить количественные показатели экономии или каких-либо других факторов, повлиявших на создание и поддержку этих изменений.
Стоит также отметить, что во многих центрах обработки данных энергопотребление, как правило, в течение 24-часового периода испытывает колебания только в пределах 4 процентов, указывая на то, что энергопотребление не зависит от загрузки системы. Благодаря последним новшествам, введенным поставщиками оборудования, эта ситуация изменилась для нового оборудования, и при более низкой загрузке количество потребляемой энергии уменьшается.

Определение экологичного центра обработки данных
Я мог бы продолжать перечисление критериев и характеристик, обеспечивающих экологичность центра обработки данных. Конечно, объем этой статьи не позволяет охватить проблему в целом, но я хочу выделить некоторые важнейшие характеристики, о которых следует помнить, если вы всерьез относитесь к реализации экологичного центра обработки данных. Даже если в настоящий момент вы находитесь только на этапе планирования, можно провести сравнение с этим списком, чтобы определить, в каком состоянии находится ваш центр обработки данных в настоящее время.
  1. Счетчики используются для анализа использования энергии на уровне отдельных компонентов (например, сервер 2U, сервер 4U, коммутатор, SAN и UPS) и определения подразделений, которые должны расплачиваться за электроэнергию, используемую этими компонентами.
  2. Использование энергии постоянно контролируется для определения уровня пиковой и низкой потребности в энергии.
  3. Энергетическая емкость контролируется на уровне всего центра обработки данных вплоть до отдельных цепей, чтобы убедиться в том, что все цепи соответствуют допустимым пределам.
  4. План энергосбережения документируется и вознаграждается.
  5. План энергосбережения регулярно пересматривается, и для устранения сбоев выполняются корректирующие действия.
  6. Определение убытков подразделений, порождаемых затратами, используется для корректировки поведения и стимулирования энергосбережения независимыми подразделениями. Этот пункт должен выполняться на уровне руководства.
  7. На серверах разрешается регулировка подачи энергии на ЦП, а эксплуатационная лаборатория измеряет диапазон потребления энергии при различных нагрузках.
  8. Для выявления горячих точек и чрезмерного охлаждения используются температурные кривые.
  9. Управление производительностью системы ИТ включает в себя проведение измерений эффективности использования энергии.
  10. Отдельным организациям предоставляется доступ к оперативным данным, что позволяет им реагировать надлежащим образом. (Организация ISO в Калифорнии пошла дальше и на своем веб-узле предоставляет общественности данные в режиме реального времени, как показано на рис. 2.)
Рис. 2 Веб-узел организации ISO в Калифорнии предоставляет оперативный моментальный снимок, отражающий текущую потребность и текущий уровень экономии энергии, запрашиваемый у потребителей
Рис. 2 Веб-узел организации ISO в Калифорнии предоставляет оперативный моментальный снимок, отражающий текущую потребность и текущий уровень экономии энергии, запрашиваемый у потребителей
Чем большее число этих характеристик внедрено в вашей организации, тем ближе вы к успешной эксплуатации современной системы текущего контроля энергопотребления. Прилагается карточка показателей (см. рис. 3), содержащая восемь вопросов, ответы на которые помогут оценить текущий уровень вашего центра обработки данных: базовый, промежуточный или передовой.
Figure 3 Насколько экологичен ваш центр обработки данных? (Close Figure 3)

Уровень | Выполняется ли ...
Базовый | Просмотр ежемесячного счета на оплату электроэнергии?
Регулярная проверка электрооборудования для планирования загрузки производственных мощностей?
Промежуточный | Автоматизированы ли процедуры измерения и составления отчетов о загрузке и потреблении для электрических цепей?
Ознакомление с энергетической эффективностью оборудования при его приобретении?
Передовой | Текущий контроль энергопотребления для стоек, устройств и цепей?
Анализ текущего контроля и отчетов для архивных данных?
Использование оперативных отчетов об энергопотреблении для отделов с целью осмысления влияния изменений и развертываний?
Использование данных для обсуждения льготных тарифов на энергию с поставщиком электроэнергии?

Знание — залог успеха
Еще одна проблема, с которой вы столкнетесь, — необходимость введения стандартов в рамках всей организации. Реализация такого изменения, как описанное в этой статье, — изменение принципа измерения энергопотребления, требующее участия всех подразделений организации, влечет необходимость четкого взаимодействия групп технического обслуживания во всех центрах обработки данных, работающих с многочисленными группами ИТ. Организационные проблемы такого рода являются основным препятствием для внедрения программы энергосбережения.
Важно обеспечить, чтобы за анализ потребления в центрах обработки данных отвечал один сотрудник или одна группа сотрудников. Этот аналитический центр (отсутствующий в большинстве компаний, когда речь идет об энергопотреблении) имеет большое значение. Важно также, чтобы используемое с собирал данные на самых разных технических средствах одинаковым способом и возвращал согласованные отчеты в каждое из подразделений (на рис. 4 показан пример инструментальной панели для формирования отчетов с данными).
Рис. 4 Пример инструментальной панели для текущего контроля всех данных (любезно предоставлен OSIsoft)
Рис. 4 Пример инструментальной панели для текущего контроля всех данных (любезно предоставлен OSIsoft)
Не имея подходящих инструментов, невозможно оценить эффективность эксплуатации, и конкретные подразделения не смогут понять, достигают ли их усилия результата. Если вы действительно намерены изменить поведение сотрудников, вам потребуется в режиме реального времени предоставлять пользователям информацию с тенденциями в изменениях журнальн данных, чтобы они могли наглядно увидеть результаты своих действий. Невозможно эффективным образом вознаграждать рабочие группы за их достижения в эффективном использовании энергии, если для составления отчетов о достигнутых результатах во всех подразделениях не будут использоваться одинаковые системы, одинаковые наборы инструментов и выполняться одинаковые измерения.

Силы отрасли
Вы не одиноки в своих усилиях сделать вашу компанию более экологичной. Лидеры других рынков — от таких компаний, как Boeing и Toyota и до правительственных агентств, например, штата Калифорния, — делают серьезные финансовые вложения, чтобы их производственная деятельность и готовая продукция стали более экономными с точки зрения энергопотребления.
Что касается мира ИТ, то в 2006 г. палата представителей США приняла законопроект —H.R. 5646, являющийся в настоящее время общественным законом 109-431, призывающий Агентство по охране окружающей среды (EPA) исследовать энергетические затраты и потребление электроэнергии серверами и центрами обработки данных и потенциальный эффект от перехода на системы, более эффективно использующие энергию. В исследовании, проведенном в рамках ENERGY STAR, программы EPA, представлен краткосрочный прогноз роста использования в США энергии компьютерами-серверами и центрами обработки данных; проведена оценка потенциальных затрат и энергосбережения, связанных с усовершенствованиями, влияющими на эффективное энергопотребление компьютерами-серверами и центрами обработки данных, и оценены возможные стимулы и благотворительные программы, направленные на продвижение компьютеров-серверов и центров обработки данных, эффективно использующих энергию. Окончательные результаты данного исследования были представлены Конгрессу в августе 2007 г. Более подробную информацию об этом исследовании см. на веб-узле по адресу energystar.gov.
Разрабатываются также новые стандарты строительства экологичных зданий. Эти стандарты предусматривают такие критерии, как средства дополнительных почасовых измерений для цепей в зависимости от их назначения и энергопотребления; счетчики для зданий, передающие данные о потреблении энергии в систему управления данными от счетчиков; и системы управления данными счетчиков для хранения данных и создания пользовательских отчетов, отражающих почасовое, ежедневное, ежемесячное и ежегодное потребление энергии, фиксируемое каждым счетчиком. Соблюдение многих из этих критериев требуется системами контроля, если вы подписываетесь на программы энергосбережения, в которых требуется доказать, что внесенные изменения дали результат (например, программы кредита возобновляемой энергии, углеродных кредитов и программы пониженного энергопотребления).
Некоторые пользователи интересовались тестированием технических характеристик, но представить полный перечень применений затруднительно. Делались попытки стандартизации тестов, но такие тесты, как и большинство тестов производительности, используются для оптимизации «наблюдаемых» результатов, которые не отражают фактического использования. Рассмотрим, например, мили на галлон (MPG). Нормативы EPA оценивают мили на галлон, характерные для типичного водителя при движении в обычных городских условиях и условиях движения по скоростной магистрали, однако большинство водителей и условий вождения отличаются от типичных, и факторы, влияющие на эффективность использования горючего, могут существенно различаться. Это же правило применимо к энергосбережению в центре обработки данных. Точные результаты для вашей организации могут быть получены только в результате измерения показателей энергосбережения в вашей собственной рабочей среде.

Как достигается экономия?
При определении показателей экономии следует учитывать множество факторов. Известна ли вам стоимость увеличения потребления энергии на конкретном участке? Есть ли у вас стратегия для минимизации ограничений на мощность? Нельзя ли решить задачу, разместив центр данных в каком-нибудь месте с более дешевой энергией, или же следует сосредоточиться на усовершенствовании производственного процесса в существующих условиях?
Для некоторых компаний оптимальным способом снижения затрат может оказаться перемещение центров данных в области с более дешевыми источниками электроэнергии. Виртуализация серверов предлагает другой подход к снижению энергопотребления. Фактически, некоторые энергетические компании (PG&E, SoCal Edison и SDG&E – только часть из них) предлагают финансовые стимулы потребителям, реализующим проекты виртуализации серверов, которые приводят к сокращению серверного оборудования.
Но можно предпринять и более простые, менее радикальные действия. В настоящее время большинство отделов ИТ не имеют представления о том, какое количество энергии потребляют их системы, и это означает, что у них имеются широкие возможности для потенциальной экономии. Для начала можно оценить энергопотребление, связанное с отдельными устройствами, а затем посмотреть, нельзя ли провести какие-либо изменения на уровне устройств. Большое число небольших изменений может внести существенный вклад в экономию.
Для сравнения представим себе типичное домашнее хозяйство, хозяин которого не имеет понятия о том, какое количество энергии в их доме использует каждое устройство — они просто платят по общему ежемесячному счету. Можно приобрести простое и недорогое устройство, например, Kill A Watt, измеряющее энергопотребление отдельных устройств. Сколько вы тратите на поддержание микроволновой печи во включенном состоянии в то время, когда не пользуетесь ею? Какое количество энергии потребляется подключенным к розетке зарядным устройством для телефона? Пользуясь этим же подходом, можно установить измерители мощности на стойках и собирать данные с различных устройств. Инструменты управления можно использовать для сбора данных непосредственно с некоторых серверов с ловушками SNMP энергопотребления.

Начало работы
На рис. 5 представлена схема оптимальных методик, рекомендуемых для использования на начальном этапе планирования. На этом этапе важно понимать, что вы не ограничены выбором из двух крайностей. Можно предпочесть более сбалансированный подход, который, возможно, бол ее реалистичен. Начните действовать «снизу», выяснив, кто в вашей компании увлечен идеей энергосбережения. Начните с измерений на некоторых устройствах подразделения, чтобы сделать проблему наглядной. Создание некоторого импульса и демонстрация поддающихся количественному определению результатов поможет получить поддержку, необходимую для увеличения инвестиций компании в решение задачи перехода к экологичному производственному процессу.
Figure 5 Решающие факторы для внедрения плана энергосбережения (Close Figure 5)

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

За плечами Дейва Охара (Dave Ohara) 26-летний опыт работы с технологиями таких компаний как Майкрософт, Apple и Hewlett-Packard. Занимавшийся в прошлом разработками, маркетингом, просвещением в области техники, архитектурой инфраструктур, разработкой технологических цепочек обработки данных, решением задач по обеспечению надежности работы систем и логистикой оптовой торговли, в настоящее время Дейв работает с множеством компаний, сосредоточившись на реализации «зеленых» инициатив.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Администрирование в Windows: Руководство по репликации Active Directory
Администрирование в Windows Лора Хантер (Laura E. Hunter)

Руководство по репликации Active Directory
Краткий обзор:
  • Переход к Active Directory
  • Поддержание согласованности
  • Разрешение конфликтов
  • Изменения в Windows Server 2008

До внедрения Windows 2000 Server и Active Directory во многих корпоративных сетях для поддержания серверной инфраструктуры и управления идентификацией и правами доступа использовалась ОС
Windows NT. До выпуска Windows NT® 4.0 она была цельным предложением на рынке сетевых операционных систем, однако у нее был ряд недостатков, затрудняющих ее развертывание на большом предприятии.
Прежде всего, в Windows NT для именования сетевых ресурсов использовалось одноуровневое пространство имен. В результате не существовало удовлетворительного способа разделить ресурсы на меньшие подмножества или настроить хоть какое-то групповое администрирование. Например, нельзя было создать отдельный контейнер для ресурсов отдела маркетинга или назначить локального администратора с правом изменения паролей только для пользователей этого отдела. Безопасность в Windows NT в основном строилась по принципу «все или ничего». Если нужно было делегировать часть административных заданий инженеру технической поддержки настольных компьютеров, часто не оставалось ничего другого, кроме как давать ему намного больше полномочий, чем можно было бы при другой модели безопасности.
Кроме того, вся информация Windows NT сохранялась в базе данных диспетчера учетных записей безопасности (SAM), объем которой не мог превышать 40 МБ. Если база данных SAM вырастала больше рекомендованного максимума (примерно 25000-40000 объектов, в зависимости от настройки), приходилось делить сеть на несколько отдельных доменов, что усложняло администрирование сети и предоставление пользователям доступа к ресурсам. Каждый домен NT содержал один и только один основной контроллер домена с копией базы данных SAM, доступной на запись и чтение. Кроме него для защиты от сбоев в домене можно было создать один или несколько резервных контроллеров домена. Резервные контроллеры содержали копию базы, открытую только, на чтение и модифицировать данные они не могли. Поэтому им нельзя было, например, менять пароли пользователей, поскольку это требует доступа на запись.
Наконец, Windows NT основывался на разрешении имен NetBIOS. Основой этого протокола были широковещательные сообщения, что создавало существенный трафик при просмотре пользователем сетевых ресурсов. Особенно большая нагрузка появлялась, когда сообщения должны были пройти через медленный или сильно загруженный канал глобальной сети.

Появление новой модели
В 2000 году Microsoft выпустил Windows® 2000, являющийся значительным шагом вперед по сравнению с предыдущими NOS. Новая служба сетевой ОС, Active Directory®, настолько отличалась от Windows NT, насколько это можно себе представить. Вместо того, чтобы опираться на одноуровневое пространство имен, Active Directory была построена на стандарте X.500, предполагающем создание иерархических организационных структур. Ресурсы можно было объединять в многочисленные организационные подразделения внутри одного домена и делегировать администрирование каждым подразделением на уровне задач.
Другим заметным отходом от Windows NT стала новая модель репликации — репликация с несколькими хозяевами. Вместо единственного пишущего основного контроллера домена и связанных с ним резервных контроллеров домена в Active Directory каждый контроллер домена может записывать в базу данных Active Directory.
Тем не менее, хотя в результате и получается большая гибкость при поддержке большой или децентрализованной сети, возникают трудности с поддержанием целостности Active Directory. Если Иван Кузнецов и Мария Петрова внесут изменения в один и тот же объект в филиалах, находящихся в разных концах страны, что произойдет, если их изменения приведут к конфликту? Модель репликации Active Directory определяет способы, с помощью которых обновления передаются всем доменными контроллерами сети, а также как разрешаются конфликты, возникающие в результате возможности многих хозяев вносить изменения почти откуда угодно.

Механизмы репликации Active Directory
В этих примерах будет обсуждаться только внутрисайтовая репликация. Внутрисайтовая репликация сделана для того, чтобы быстро передавать изменения между доменными контроллерами в пределах одного сайта, используя сообщения об изменениях. В случае внутрисайтовой репликации DC1 сообщает DC2 о том, что у него есть изменения, которые надо реплицировать, после чего DC2 запрашивает эти изменения у DC1. Подобным же образом DC2 сообщает об изменениях DC1, после чего DC1 запрашивает эти изменения у DC2. Видно, что репликация Active Directory происходит с помощью запросов, а не с помощью принудительной отправки.
Поскольку Active Directory может масштабироваться до сотен тысяч и даже миллионов объектов, необходимо разбивать базу данных Active Directory на части. Эти части называются контекстами именования (NC). Каждый контроллер домена хранит как минимум три контекста именования в своей локальной копии базы данных Active Directory.
Контекст именования «Схема» Этот контекст именования реплицируется на все остальные контроллеры доменов в лесе. В нем содержится информация о схеме Active Directory, которая определяет классы объектов Active Directory и их атрибуты.
Контекст именования «Конфигурация» Реплицируемый, как и «Схема», на все остальные контроллеры домена в лесе, этот контекст именования содержит информацию о конфигурации физического расположения Active Directory на уровне леса, о спецификаторах отображения и о квотах на уровне леса для Active Directory.
Контекст именования «Домен» Этот контекст именования реплицируется всем остальным контроллерам доменов в пределах одного домена Active Directory. В этом контексте именования находятся наиболее часто запрашиваемые данные Active Directory: реальные пользователи, группы, компьютеры и другие объекты, находящиеся внутри домена Active Directory.
Чтобы лучше оптимизировать сетевой трафик, каждый контекст именования реплицируется отдельно. Таким образом, редко меняющиеся контексты, такие как «Схема», не занимают часть пропускной способности сети, необходимую контексту «Домен», который меняется намного чаще.
Поскольку с любого контроллера домена Active Directory можно вносить изменения, репликация Active Directory должна отслеживать два типа операций записи. Один тип — это порождающие записи, когда какие-то изменения вносятся в некоторый контроллер домена напрямую. Например, можно подключиться к DC1 и поменять пароль пользователя. Это изменение считается порождающей записью в DC1. Кроме того, Active Directory должна отслеживать реплицированные записи — это, как можно предположить, те изменения, которые реплицированы с другого контроллера домена. Изменение, которое было порождающей записью для DC1, будет считаться реплицированной записью на DC2, DC3 и всех прочих контроллерах домена в домене.
Контроллеры доменов Active Directory управляют передачей изменений каталога с помощью метаданных репликации. Это значит, что кроме обмена самими изменившимися данными между контроллерами доменов (новое описание Ивана Кузнецова — «Начальник отдела кадров») Active Directory передает дополнительную информацию об этом изменении, позволяя контроллерам домена выполнить репликацию наиболее эффективно. В эту дополнительную информацию могут входить контроллер домена, с которого пришли изменения, время, когда изменение произошло, и другие ключевые данные.
Обсудим для начала элемент метаданных репликации, называемый номером последовательного обновления (USN). Каждый контроллер домена поддерживает USN, который ему специфичен. Как только данный контроллер домена вносит изменения в Active Directory, к значению USN прибавляется 1. Если у DC был USN, равный 1000 в 11:00 утра, и 1005 в 11:30 утра, значит, на этом DC был сделано 5 изменений базы данных Active Directory. C точки зрения USN неважно, какими именно были изменения. И при модификации, и при удалении, и при создании, и при любых комбинациях действий над 5 объектами значение USN контроллера домена увеличится ровно на 5. Более того, USN существуют только в пределах определенного контроллера домена, между USN разных контроллеров домена нет никакой связи, и сравнивать их значения нельзя. Один контроллер в домене может внести изменения в 11:30 и присвоить USN значение 1051. Второй контроллер того же домена может внести изменения в тот же самый момент, что и первый, но присвоить USN значение 5084. Эти два контроллера домена будут иметь совершенно разные USN для изменений, происшедших почти одновременно. Однако на репликацию изменений это никак не повлияет, потому что сравнение номеров последовательного обновления для разных контроллеров домена не имеет смысла.
Однако USN может увеличиваться и по другим причинам. Выше говорилось, что изменения в базе данных Active Directory состоят из порождающих и реплицированных записей. Номер последовательного обновления контроллера домена увеличивается обоими типами операций на запись, то есть всякий раз, когда изменения реплицируются с другого контроллера домена. Очевидно, что каждому контроллеру домена нужно как-то следить за тем, какие изменения уже реплицировались, иначе при каждой репликации отправлялась бы вся база данных Active Directory. Чтобы этого не произошло, каждый контроллер домена Active Directory поддерживает величину, называющуюся вектором верхних пределов (HWMV) для всех остальных контроллеров домена, с которыми происходит обмен данными при репликации. Каждый контроллер домена связывает этот вектор верхних пределов с глобальным уникальным идентификатором (GUID) удаленного контроллера домена, чтобы предотвратить путаницу в случае, если этот контроллер домена переименуют или удалят из каталога.
Начнем с простого примера. Пусть есть два контроллера, настроенных в домене contoso.com, dc1.contoso.com и dc2 contoso.com. Поскольку в домене contoso.com только два контроллера домена, репликация будет происходить только между DC1 и DC2. (В этом упрощенном примере не раскрыт полный механизм репликации, в дальнейшем к нему будут добавлены дополнительные детали).
Пусть USN у DC1 равен 3000, у DC2 4500 и оба контроллера домена на начало примера обновлены.
Шаг 1: DC1 и DC2 обновлены друг относительно друга. У DC1 есть вектор верхнего предела для DC2 со значением 4500, у DC2 вектор верхнего предела для DC1 со значением 3000, как показано на рис. 1.
Рис. 1 Текущее состояние двух контроллеров домена
Рис. 1 Текущее состояние двух контроллеров домена
Шаг 2: Администратор создает новый объект на DC1, USN DC1 увеличивается до 3001, как показано на рис. 2. Заметьте, что HWMV DC1 на DC2 не изменился, потому что DC1 еще не сообщил DC2 о том, что у него есть ожидающие репликации изменения.
Рис. 2 Добавлен новый объект
Рис. 2 Добавлен новый объект
Шаг 3: DC1 сообщает DC2 об изменении. Затем DC2 начинает репликацию с DC1, чтобы запросить все доступные изменения. Как часть запроса, DC2 отправляет DC1 вектор верхнего предела, который хранился для DC1, как показано на рис. 3.
Рис. 3 Оповещения об изменениях
Рис. 3 Оповещения об изменениях
Шаг 4: DC1 отправляет на DC2 изменение, соответствующее USN 3001, то есть тот объект, который был создан на DC1 в шаге 2. DC2 обновляет свой USN до 4501 и свой HWMV для DC1 до 3001, как показано на рис. 4.
Рис. 4 Изменения и обновления
Рис. 4 Изменения и обновления
Пока все идет нормально. Но есть проблема. У DC2 есть изменения, которые нужно реплицировать. Если единственными ориентирами являлись бы номера USN и векторы верхнего предела, в этот момент DC2 связался бы с DC1 чтобы реплицировать назад на DC1 то же изменение, которое DC1 только что реплицировал на DC2. В результате образовался бы бесконечный цикл репликации, который постепенно занимал бы все большую и большую долю пропускной способности. Чтобы бороться с этим, нужно поставить на место еще несколько кусочков головоломки, первый из которых — вектор синхронизации (вектор UTD или просто UTDV).
Вектор синхронизации — это еще одна часть метаданных репликации. Он используется для предотвращения распространения, то есть его назначение состоит в том, чтобы предотвратить исчерпание полосы пропускания повторной репликацией одного и того же изменения. Каждый контроллер домена поддерживает таблицу вектора синхронизации для каждого другого контроллера домена, в которой хранится реплика рассматриваемого контекста именования. Для каждого контекста именования «Домен» каждый контроллер домена в домене поддерживает вектор синхронизации для каждого контроллера домена в домене; контексты именования «Конфигурация» и «Схема» поддерживаются каждым контроллером домена в лесе. Таблица вектора синхронизации не только следит за максимальным USN, который каждый контроллер домена получает от своих партнеров по репликации, но и за максимальным USN, получаемым от каждого контроллера домена, замещающего данный контекст именования. Чтобы это стало возможным, каждое изменение при репликации включает следующую информацию:
  • Номер GUID контроллера домена, который реплицирует изменение. Это может быть изменение, которое реплицируется как порождающая запись или как реплицированная запись.
  • USN контроллера домена, который реплицирует изменение. Оно тоже может быть от порождающей или реплицированной записи.
  • Номер GUID контроллера домена, который реплицирует изменение. Если этот номер GUID равен номеру GUID контроллера домена, пославшему репликацию, то это порождающая запись. Иначе в дело вступает таблица вектора синхронизации.
  • USN контроллера домена, являющегося источником изменения. Опять же, если этот номер GUID равен номеру GUID контроллера домена, пославшему репликацию, то это порождающая запись. Иначе, это из таблицы вектора синхронизации.
Чтобы лучше проиллюстрировать процесс, усложним пример и добавим третий контроллер домена, DC3. В этом случае DC1, DC2 и DC3 являются партнерами репликации друг для друга. DC1 реплицируется с DC2 и DC3, DC2 с DC1 и DC3, и DC3 с DC1 и DC2:
Шаг 1: DC1, DC2 и DC3 все обновлены друг относительно друга.
Шаг 2: DC3 производит одну порождающую запись, изменяя пароль учетной записи пользователя икузнецов. DC3 сообщает DC1 и DC2 о доступном изменении. DC1 и DC2 запрашивают порождающую запись с DC3, а потом обновляют свои HWMV и таблицы векторов синхронизации для DC3, как показано на рис.5.
Рис. 5 Обновление таблиц HWMV и векторов синхронизации
Рис. 5 Обновление таблиц HWMV и векторов синхронизации
Шаг 3: На этом шаге начинает работать вектор синхронизации. DC2 сообщает DC1, что у него есть изменения. DC1 связывается с DC2, запрашивая новые изменения. При этом DC2 передается следующая информация:
  • Верхний предел DC1 для DC2, в данном случае 4501.
  • Таблица вектора синхронизации контроллера домена DC1 (показано на рис.6), указывающая максимальный порождающий USN, который получили все контроллеры домена, включая DC3.
Figure 6 Таблица вектора синхронизации. (Close Figure 6)

Все контроллеры домена, реплицирующие этот контекст именования | UTDV
<Номер GUID контроллера DC2> | 4501
<Номер GUID контроллера DC3> | 7002
Основываясь на значении HWMV 4501, DC2 решает, что он не реплицировал изменения примера на DC1 (see рис.7).
Figure 7 Изменение, которое нужно реплицировать (Close Figure 7)

Свойство | Значение | Номер GUID локального контроллера домена | Локальный USN | Номер GUID исходного контроллера домена | Оригинальный USN
Свойство пароль икузнецов | %#FH%2rfg2 | <Номер GUID контроллера DC2> | 4501 | <Номер GUID контроллера DC3> | 7002
Однако на основании данных таблицы вектора синхронизации, которую передал перед началом репликации DC1, DC2 выясняет, что DC1 не нуждается в этом изменении, поскольку он уже получил его от DC3. В этот момент DC1 только обновляет свой HWMV для DC2, отображая увеличенный USN, как показано на рис. 8. Однако для того, чтобы сохранить пропускную способность, сами данные по сети не передаются.
Рис. 8 Гашение распространения
Рис. 8 Гашение распространения
Шаг 4: Такое же гашение распространения происходит, когда о наличии изменений DC2 оповещает DC3, и когда DC1 также оповещает DC2 и DC3. Все три контроллера домена обновят свои соответствующие вхождения HWMV для всех партнеров репликации, как показано на рис. 8, однако сами данные не будут передаваться по сети, потому что они уже передались каждому контроллеру домена на шаге 2.

Разрешение конфликтов в среде с несколькими хозяевами
До сих пор наши примеры описывали идеальный мир, где только один администратор вносил изменения на контроллер домена в каждый момент времени и никто никому на ноги не наступал. Однако в реальном мире такое случается редко. Поскольку обновления объектов Active Directory могут поступить от любого контроллера в домене, что будет, если два администратора сделают несовместимые изменения с двух разных контроллеров домена? Существуют три типа конфликтов, которые происходят в Active Directory, для каждого из которых есть свой метод разрешения.
Конфликтующие изменения свойств . Такой конфликт происходит, когда два администратора обновляют один объект, так что возникает конфликт: один администратор устанавливает описание пользователя «Маркетинг», а другой администратор с другого контроллера домена — «Маркетинг и продажи».
Создание новых конфликтующих объектов . Конфликт происходит, когда два администратора создают объект с одним и тем же именем в одно и то же время, например двух пользователей икузнецов.
Перемещение объекта в удаленный контейнер . Эти конфликты случаются гораздо реже, и происходят, когда один администратор создает или перемещает объект в контейнере, таком как организационное подразделение, а другой администратор в то же время удаляет этот контейнер с другого контроллера домена.
Говоря о первых двух типах конфликтов, рассмотрим еще две составляющих метаданных репликации, использующихся в основном для разрешения конфликтов. Каждому атрибуту объекта назначается величина versionID, устанавливаемая в единицу при создании объекта. Величина versionID увеличивается на 1 каждый раз, когда контроллер домена модифицирует атрибут. Таким образом, если атрибут «описание» некоторого пользователя меняется со значения по умолчанию (пусто или <не установлено>) на «Отдел маркетинга», versionID этого атрибута станет равен 2. Если позже описание поменяется на «Отдел продаж и маркетинга», versionID будет равен 3, и так далее. versionID включается в каждый элемент репликации вместе с другими, уже рассмотренными здесь метаданными.
С помощью versionID можно еще больше сократить трафик, требующийся репликации. Например, если администратор DC2 несколько раз менял один атрибут (возможно, он или она несколько раз опечаталась), так что порождающие записи DC2 соответствуют значениям versionIDs 2, 3, 4, and 5, DC2 реплицирует только ту запись, которая соответствует последнему versionID, равному 5. Поскольку более ранние изменения все равно переписаны, то, не отправляя их, можно уменьшить нагрузку на сеть.
Каждое изменение Active Directory включает еще одну составляющую метаданных, используемую для разрешения конфликтов — временную метку, указывающую на время обновления.
Временная метка используется и для упреждающей оценки работоспособности репликации Active Directory. Если один контроллер домена не видит никаких изменений с относительно новыми временными метками от другого контроллера домена, он начинает создавать сообщения об ошибке, указывая на возможную неисправность другого контроллера домена.
Как же используются эти атрибуты для разрешения конфликтов? Давайте рассмотрим каждый тип конфликта по порядку.

Разрешение конфликта при изменении свойств
Рассмотрим в качестве примера объект пользователя икузнецов в домене contoso.com. Администратор DC1 меняет описание икузнецова на «Маркетинг». Почти одновременно с ним, администратор DC3 меняет то же описание пользователя на «Продажи и маркетинг». Информация об атрибуте «описание» для икузнецов на DC1 и DC3 в этот момент показана на рис. 9.
Figure 9 Почти одновременные изменения (Close Figure 9)

Сервер | Свойство | Значение | VersionID | Временная метка. | Номер GUID локального контроллера домена | Локальный USN | Номер GUID исходного контроллера домена | Оригинальный USN
DC1 | Свойство «описание» икузнецов | маркетинг; | 2 | 2007-06-07 14:03:25 | <Номер GUID контроллера DC1> | 3003 | <Номер GUID контроллера DC1> | 3003
DC3 | Свойство «описание» икузнецов | Сбыт и маркетинг | 2 | 2007-06-07 14:04:57 | <Номер GUID контроллера DC3> | 7003 | <Номер GUID контроллера DC3> | 7003
Если DC2 получит оба изменения одновременно, ему придется определять, какое из них «победило». Порядок разрешения конфликта таков:
  1. Модификация с большим значением versionID считается «победительницей»; «проигравшая» модификация переписывается. В данном случае versionID для обеих записей равен 2, так что используем следующий критерий.
  2. Если у двух записей одинаковый versionID, изменение с более поздней временной меткой будет принято как выигравшее, проигравшее изменение будет переписано. В данном случае временная метка порождающей записи DC3 позже, поэтому описание икузнецова будет установлено в «Продажи и маркетинг». В тех редких случаях, когда и versionID, и временная метка одинаковы, нужен третий и определяющий критерий:
  3. Если versionID и временная метка совпадают у обеих записей, выигрывает то изменение, которое пришло от контроллер домена с меньшим номером GUID; запись с большим номером GUID перепишется. Если у DC1 номер GUID равен 1234567890, а у DC3's равен 2345678901, то запись от DC1 выигрывает при одинаковых versionID и временной метке.
Возможно, вы задумались: «А не стоило ли сделать временную метку первым критерием выигрыша?» Это не такое шаблонное решение, как можно подумать. Если бы первичным критерием при разрешении конфликтов Active Directory являлись временные метки, то злонамеренный администратор мог бы распространить свои изменения на всю сеть, просто переставив часы на одном из контроллеров домена так, чтобы временная метка этого контроллера домена всегда выигрывала конфликт.

Разрешение конфликта создания объектов
В случае создания двух объектов с одинаковыми именами Active Directory использует перечисленные выше три критерия чтобы определить, какой объект «выиграет». Правда, в отличие от предыдущей ситуации, «проигравший» объект не перезаписывается. Вместо этого проигравший объект переименовывается с использованием символов CNF (конфликтный объект), за которым следует двоеточие и номер GUID «проигравшего» объекта.. Это позволяет администратору позже принять более обоснованное решение о том, какой объект оставить, а какой удалить.

Разрешение перемещения объекта в удаленный контейнер
Как уже было упомянуто, разрешение конфликта с помещением объекта в удаленный контейнер происходит нечасто и обычно является результатом одной из двух ситуаций. В одной администратор одного контроллера домена создает объект в каком-то контейнере, например в организационном подразделении Тренировочный, а то же самое время, когда другой администратор с другого контроллера домена удаляет организационное подразделение Тренировочный. Вторая ситуация может произойти, когда администратор одного контроллера домена перемещает объекты в контейнер в то же самое время, когда администратор другого контроллера домена удаляет этот контейнер.
В этом случае разрешение довольно просто: Active Directory перемещает «осиротевший» объект в специальный контейнер Active Directory, разработанный специально для таких случаев. Он является потомком корня каждого домена Active Directory. В домене contoso.com контейнер LostAndFound находится вдоль следующего пути LDAP: LDAP://cn=LostAndFound,dc=contoso,dc=com. Если вы не видите контейнера LostAndFound, когда вы открываете оснастку «Active Directory – пользователи и компьютеры», просто выберите «Вид|Дополнительно».

Защита от отката USN
Одну из самых тяжелых ситуаций, с которой можно столкнуться в работе с Active Directory, одновременно проще всего предотвратить, если знать ее причину и способы устранения. Откат USN — это ошибка, которая может полностью заблокировать репликацию в сети. Она появляется в результате возврата в сеть контроллера домена, который слишком долго был отключен от сети, или после неправильного восстановления контроллера домена.
Одна из причин, вызывающая откат USN, находится в способе удаления объектов в среде с несколькими хозяевами. Когда на контроллере домена удаляется объект, он не убирается из системы тут же, а помечается как удаленный. В этом состоянии он может реплицироваться другие контроллеры домена, тем самым сообщая о своем удалении. Объект, помеченный на удаление, имеет атрибут isDeleted, равный «ИСТИНА». Для того, чтобы уменьшить количество объектов, помеченных на удаление, большинство значений объекта (описание, личная информация и членство объекта в группах) удаляется. (дальнейшие сведения об этом процессе приведены в статье Длил Киркпатрик (Gil Kirkpatrick) «Реанимация объектов-захоронений Active Directory» (Reanimating Active Directory Tombstone Objects), доступную на веб-странице technetmagazine.com/issues/2007/09).
Откат USN происходит потому, что помеченные на удаление объекты не остаются в системе навечно. По умолчанию, они полностью стираются из базы данных через 60 или 180 дней (в зависимости от версии Windows Server ®, в которой впервые создавалась среда Active Directory. Эти 60 или 180 дней называются «временем жизни захоронения». Все контроллеры доменов должны реплицироваться хотя бы раз в течение этого времени, иначе они становятся хуже, чем бесполезными — они создают возможность отката USN. Откат USN происходит, когда контроллер домена настолько долго не обновлялся, что он пропустил один или нескольких объектов-захоронений, в результате он не способен построить полностью обновленную структуру базы данных. Чтобы защититься от этого, каждый контроллер домена, который отсутствовал в сети дольше, чем время жизни удаленных объектов, нельзя возвращать к обслуживанию сети. Вместо этого сервер нужно собрать заново, удалив старые метаданные этого сервера из Active Directory, используя шаги, описанные в статье 216498 (support.microsoft.com/kb/216498) базы знаний Майкрософт.
Вторая причина отката USN — восстановление контроллера домена неправильным способом, в основном используя клонирование дисков или снятие их образов. Когда это происходит, восстановленная база данных Active Directory не может сразу понять, что она «перенеслась в прошлое», потому что использованный метод восстановления не учитывал Active Directory. В Windows 2000 и Windows 2003 распознать откат USN было сложно, но Windows Server 2003 SP1 (и ожидаемый Windows Server 2008) имеют внутренние механизмы контроля, определяющие, правильно ли был восстановлен контроллер домена. В этих ОС новых версий контроллер домена будет записывать события с идентификаторами 1115, 2095, 2103, и 2110 в журнал событий службы каталогов. Текст этих сообщений, так же как и необходимые шаги по восстановлению после отката USN, можно прочитать в статье 875495 базы знаний (support.microsoft.com/kb/875495) по Windows Server 2003. (Сведения о том, как справляться с откатом USN в Windows 2000, находятся в статье 885875 базы знаний, доступной на support.microsoft.com/kb/885875.)

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

Лора Хантер (Laura E. Hunter) является четырехкратным лауреатом премии Microsoft MVP в области средств для работы с сетью Windows Server. Она ветеран информационных технологий с десятилетним стажем работы, автор и соавтор многочисленных книг, статей и технических документов, в том числе второго издания «Справочного руководства по Active Directory» (изд-во O'Reilly, 2006).


 Системный центр : Новые средства управления обновлением программного обеспечения
Системный центр Стив Рачуи (Steve Rachui)

Новые средства управления обновлением программного обеспечения
Краткий обзор:
  • Старый способ управления обновлениями
  • Новый процесс в SCMM 2007
  • Настраиваемая конфигурация и гибкость
  • Точное расписание обновлений

Управление обновлением программного обеспечения впервые было применено в Systems Management Server (SMS) 2.0 и содержало средство поиска обновлений безопасности и Office. Было выпущено несколько версий перечисленных ниже средств: расширенное
средство обновления безопасности, которое получило возможность поиска для других продуктов; средство учета обновлений Microsoft®, которое стало совмещать средства для безопасности и Office в одном продукте; и средство учета обновлений Dell. Также было создано средство публикации пользовательских обновлений для поддержки исправлений продуктов сторонних производителей. Средство ITMU (Inventory Tool for Microsoft Updates – средство учета для центра обновления Майкрософт) также было выпущено в трех версиях. Каждое из этих средств имеет собственные каталоги, инфраструктуру поиска и особые требования и задачи. Со временем каталоги для этих систем стали очень большими, такими большими, что из-за ограничений по объему старые обновления пришлось удалять ради добавления новых.
Развертывание обновлений с помощью этих средств, с учетом разнообразия параметров, может оказаться затруднительным. Было очевидно, что процесс необходимо упростить. Следующий выпуск SMS— System Center Configuration Manager 2007 (SCCM) значительно продвигается в этом направлении. Механизм обновления программного обеспечения в SCCM сделан так, чтобы обеспечить лучшие итоговые результаты. Благодаря совершенно иному подходу к операциям управления обновлениями старые каталоги и механизмы поиска уходят в прошлое. Состояние обновления, исторически передаваемое через реестр оборудования, использует новый механизм – сообщение о состоянии, позволяющий лучше определить соответствие и обеспечить установку для каждого клиента. Я уверен, что вы согласитесь: новый подход к управлению обновлениями в SCCM 2007 – это значительное улучшение.
В SCCM 2007 представлены два новых компонента, о которых я расскажу прежде, чем мы углубимся в функции управления обновлением.
Точка обновления программного обеспечения (SUP) Как уже говорилось, в SCCM больше нет каталогов. Вместо этого SCCM работает напрямую со специальным сервером служб Windows Server® Update Services (WSUS), который действует как точка обновления программного обеспечения (SUP) и обеспечивает загрузку метаданных и проверку клиента. В SCCM функция доставки файла обновления в WSUS отключена, чтобы сконцентрироваться на процессе проверки. Благодаря этому WSUS теперь справляется с проверкой до 25000 клиентов на каждый SUP на выделенном сервере. SCCM также позволяет настраивать SUP в кластере балансировки сетевой нагрузки (NLB), обеспечивая дополнительную доступность и производительность, что дает возможность использовать на один основной сайт до четырех SUP, дающих в сумме 100000 клиентов.
Элементы конфигурации (CI) Элемент конфигурации – это новый подход, используемый в SCCM, позволяющий установить определенные конфигурации, которые должны иметься на конечных системах. Управление обновлением SCCM теперь использует эту инфраструктуру. Теперь обновления не укладываются в термины обычного распространения программного обеспечения, хотя некоторые сходства сохраняются. Обновления находятся в своем собственном узле на консоли администратора и используют этот совершенно уникальный механизм CI. На стороне клиента обновления загружаются и хранятся локально.

Настройка управления обновлением
Настройка управления обновлением делится на три основные области: включение агента клиента, настройка SUP и настройка распространения обновлений.
Агент клиента SCCM (показан на рис. 1) похож на другие клиентские агенты и настраивается в том же узле административной консоли. Страница свойств узла клиентских агентов обновлений программного обеспечения – это то место, где администраторы включают этот агент и настраивают установку обновления и параметры переоценки развертывания. Параметр, включающий клиентский агент обновления программного обеспечения, действует на всем сайте, иными словами, эта роль будет включена для любого клиента SCCM, принадлежащего к сайту, где включена эта функция. Если в данной среде некоторые системы не должны включать эту функцию, параметр, действующий на всем сайте, можно переопределить для каждой системы в отдельности с помощью параметров переопределения локальной политики.
Рис. 1 Свойства агента клиента
Рис. 1 Свойства агента клиента
Здесь администратор также может с помощью параметров указать, как обращаться с крайними сроками обновлений. Представим себе, например, что есть четыре обновления, ждущих установки, и одно из них (обновление А) имеет крайний срок на день больше, чем другие. Однако допустим, что лучше установить все четыре обновления сразу, даже те, для которых еще не наступил крайний срок. Параметр на этой вкладке Enforce all mandatory deployments (Выполнять все обязательные развертывания) позволяет это настроить. Более того, эти параметры позволяют администратору указать, чтобы все уведомления и видимые так или иначе проявления процесса обновления подавлялись. Эти параметры показаны на рис. 1.
Параметры на вкладке Deployment Re-evaluation (переоценка развертывания) позволяют администраторам создавать расписание переоценки развертываний. Клиенты SCCM будут оцениваться согласно этому расписанию на предмет того, нужны ли еще установленные ранее обновления, а если они отсутствуют, устанавливать их заново.

Настройка SUP
Как упоминалось ранее, SUP – это компонент, ответственный за загрузку всей доступной информации об обновлении по расписанию и за взаимодействие с клиентами SCCM, нужное, чтобы произвести проверку соответствия на основе его базы данных обновлений. Перед настройкой SUP следует установить сервер WSUS 3.0 или более поздней версии, так как процесс SUP сам по себе не устанавливает WSUS—он просто настраивает WSUS для использования SCCM. Кроме того, на сервер сайта должна быть установлена консоль администратора для связи с сервером WSUS. После того как SCCM берет на себя роль SUP на сервере WSUS, сервер WSUS предназначается для SCCM и может использоваться только для клиентов SCCM.
SUP – это новая роль системы сайта в SCCM. Для начала настройки перейдите в узел систем сайтов консоли администратора и добавьте новую систему сайта. Следующий шаг – выбрать точку обновления программного обеспечения и следовать указаниям мастера, который соберет следующую информацию:
  • Настройка прокси-сервера
  • Сведения о порте и SSL
  • Как эта SUP должна синхронизировать обновления—с Microsoft Update, через вышестоящую SUP или вручную
  • Расписание синхронизации
  • Нужные классификации обновлений, такие, как критические обновления, драйверы, обновления безопасности, накопительные пакеты обновлений и так далее
  • Доступные для обновления продукты—Windows®, Exchange, SQL Server™ и так далее (см . рис. 2)
  • Язык
Рис. 2 Параметры продукта в мастере роли на сайте
Рис. 2 Параметры продукта в мастере роли на сайте
Когда мастер завершит работу, будет установлена SUP, а внутренние настройки будут скорректированы для поддержки требований SCCM. Не помешает убедиться, что установка прошла успешно; для этого можно просмотреть SUPSetup.log, расположенный в папке журналов в месте установки SCCM.
После установки SUP следует провести синхронизацию, чтобы SUP получил обновления и сохранил в базе данных SUP и SCCM. Синхронизацию можно произвести вручную либо по расписанию, настраиваемому мастером SUP. Ручную синхронизацию обновления можно запустить в любой момент, и после установки SUP ее стоит провести. На рис. 3 показано, как это сделать.
Рис. 3 Ручная синхронизация
Рис. 3 Ручная синхронизация
Процесс синхронизации состоит из двух частей. Во-первых, настраивается сервер SUP (WSUS) для соответствия параметрам SCCM, а настроенные обновления синхронизируются с самим сервером SUP (WSUS). После этого информация об обновлении с SUP (WSUS) синхронизируется с базой данных SCCM и становится доступной для развертывания обновления. На втором шаге в базе данных SCCM создаются необходимые CI (по одному для каждого обновления программного обеспечения); это может занимать некоторое время. Начальная синхронизация часто занимает несколько часов. Ход процесса синхронизации можно просмотреть в журнале WSyncMgr, часть которого показана на рис. 4 и 5. Конкретнее, на рис. 4 показано, как процесс синхронизации запрашивает с сервера SUP (WSUS) обновление списка обновлений с Microsoft Update. На рис. 5 – запуск процесса синхронизации реестра SUP с базой данных SCCM.
Рис. 4 Синхронизация списка обновлений
Рис. 4 Синхронизация списка обновлений
Рис. 5 Синхронизация обновлений как CI в базе данных SCCM
Рис. 5 Синхронизация обновлений как CI в базе данных SCCM
После настройки сервера WSUS как сервера SUP любое управление можно осуществлять через консоль администратора SCCM. Внесение изменений непосредственно в сервер WSUS может негативно повлиять на SCCM. Более того, эти настройки каждый час сбрасываются, когда SCCM проверяет проверяет сервер SUP, чтобы убедиться в том, что настройки верны.
В многоярусной иерархии необходимо как не менее одного сервера SUP на каждый основной сайт, где будут развертываться обновления программного обеспечения. В такой иерархии эти серверы SUP будут работать с единственным сервером SUP, главным в иерархии, который синхронизируется с Microsoft Updates. Остальные серверы SUP будут синхронизироваться с настроенным вышестоящим сервером-партнером репликации SUP.

Настройка развертывания обновлений
После настройки клиентского агента и настройки и синхронизации сервера SUP можно приступать к подготовке развертывания. Во-первых, рассмотрим различные узлы пользовательского интерфейса администратора SCCM. В целом, главных узлов пять: хранилище обновлений, списки обновлений, шаблоны развертывания, управление развертыванием и пакеты развертывания.
В хранилище обновлений хранятся все синхронизированные обновления, доступные для развертывания. Обновления можно развернуть, выбрав одно или более обновление и запустив мастер развертывания обновлений программного обеспечения, который выполняет две задачи: настраивает шаблон развертывания (или выбирает один из существующих) и настраивает самое обновление. Этот процесс мы обсудим чуть позже. Список обновлений может стать довольно большим. Чтобы облегчить поиск нужных обновлений, в SCCM 2007 есть новая функция, папки поиска, основанная на 28 имеющих отношение к обновлениям критериях, в том числе Важность (Severity), Классификация (Classification), Продукт (Product), Дата выпуска (Date Released) и Преемственность (Supersendence).
Списки обновлений позволяют администраторам создавать фиксированный набор управляемых обновлений. Их можно использовать для отчетов о соответствии нормативам, создания развертываний и делегирования административных прав. После сборки это списки обновлений реплицируются по всей иерархии и используются на дочерних сайтах—как пакеты или объявления. При репликации списки обновлений не привязаны к какому-либо определенному развертыванию; это просто списки обновлений. После составления и репликации списка обновления из него можно развертывать как единый элемент, выбирая список и разворачивая обновления.

Шаблоны развертывания
Шаблоны развертывания содержат общие параметры (такие, как расписание и информация о конечной коллекции), использованные при развертывании обновлений программного обеспечения и разработанные, чтобы снизить затраты времени на администрирование при развертывании обновлений. Можно создавать шаблоны, работающие в различных условиях развертывания в данной среде, и можно использовать их в мастерах развертывания, просто выбирая подходящий шаблон. В число заполняемых шаблоном развертывания параметров входят коллекция назначения, параметры крайнего срока (показано на рис. 6), параметры перезагрузки и окна обслуживания. Во время развертывания большого количества обновлений быстродействие конечной системы может упасть, так как крайний срок всех обновлений приходит одновременно. Более того, заметьте, что параметры из шаблона применяются к развертыванию в момент создания развертывания. Они остаются в силе до тех пор, пока не будут изменены в развертывании вручную. Важно помнить, что простое изменение параметров в шаблоне после развертывания не изменит эти параметры в существующих развертываниях, использующих измененный шаблон.
Рис. 6 Установка расписаний развертывания в мастере
Рис. 6 Установка расписаний развертывания в мастере
Параметры, показанные на рис. 6, можно изменять во время работы либо мастера шаблона развертывания, либо мастера развертывания обновлений программного обеспечения (если создается новый шаблон). Обратите внимание, что параметр длительности на этом экране равен 0. Значение этого параметра по умолчанию – две недели. Если устанавливается значение этого параметра, отличное от 0, у клиента произойдет задержка перед развертыванием обновления вплоть до этого значения. Между тем моментом, когда развертывание станет доступным, и моментом, когда будет наступит указанный крайний срок, обновление будет доступно конечному пользователю для установки вручную до крайнего срока. В момент наступления крайнего срока обновление будет установлено принудительно. Если вы столкнулись с задержками в развертывании обновлений, убедитесь, что этот параметр настроен в соответствии с вашими потребностями.

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

Пакеты развертывания
Пакеты развертывания схожи со стандартными ракетами SMS в том отношении, что они определяют конкретные свойства обновления – каталог с исходными файлами, точку распространения и так далее. Пакеты развертывания не зависят от конкретного развертывания, используемого для распространения обновлений, и по сути являются хранилищем обновлений. Если необходимые для развертывания обновления содержатся более чем в одном пакете, агенты SCCM определяют, откуда лучше всего взять обновление, и могут использовать любой доступный пакет развертывания, содержащий обновление.
Для развертывания обновлений в SCCM используется мастер развертывания обновлений программного обеспечения. Этот мастер может использоваться как с отдельными обновлениями, так и со списками обновлений. Рис. 7 иллюстрирует, как запускать этот мастер.
Рис. 7 Запуск мастера развертывания обновлений программного обеспечения
Рис. 7 Запуск мастера развертывания обновлений программного обеспечения
Этот мастер спрашивает название для развертывания, использовать ли параметры существующего или нового шаблона (если выбран новый шаблон, мастер запросит описанные выше параметры шаблона), параметры пакета развертывания (готового или нового), параметры точки распространения, параметры источника для загрузки, требуемые языки обновления и информацию о расписании развертывания.
После завершения настройки будет обновлена политика, уведомляющая конечных клиентов обновлений, и обновления будут установлены на системы клиентов. Процедуры, имеющие место на стороне клиента, существенно отличаются от входящих в предыдущие выпуски и выходят за рамки этой статьи. Ключевое отличие, тем не менее, заключается в том, что проверка обновлений больше не производится локально, этим занимается сервер SUP, но подробности соответствия обновлений хранятся в локальном хранилище инструментария управления Windows (WMI), как и в предыдущих версиях.
В отличие от предыдущих версий, для отправки состояния обновления на сервер сайта больше не используется реестр оборудования. Вместо этого на сервер сайта через точку управления отправляются сообщения состояния (новый тип упрощенного сообщения состояния). Сообщения состояния предоставляют данные о всех без исключения управляемых клиентах для проверки соответствия нормативам и для отслеживания выполнения развертываний. В SCCM для управления обновлениями программного обеспечения включено несколько новых отчетов, включая общее соответствие нормативам на компьютер для всех развернутых обновлений на каждый клиент, состояние применения развертываний по клиентам и отчеты об ошибках проверки и развертываний у клиентов, дающие список главных проблем в порядке их серьезности.
В дополнение к традиционному обязательному применению развертываний обновлений по расписанию SCCM позволяет устанавливать одобренные обновления до крайнего срока, по расписанию, весьма сходному с тем, что имеет место для автоматических обновлений. Это полезное дополнение позволит еще увеличить количество соответствующих условиям систем до наступления крайнего срока развертывания.
Если вам нужны пользовательские обновления, SCCM обеспечивает и это. Средство публикации пользовательских обновлений из SMS 2003 R2 было адаптировано для использования в SCCM 2007 как средство публикации обновлений системного центра (System Center Updates Publisher)—благодаря этому любые пользовательские обновления можно развертывать уже описанным способом.
Изменения управления обновлениями в SCCM обширны, но с точки зрения администратора они упрощают использование и являются значительным шагом вперед по сравнению с предыдущими версиями. И хотя некоторые принципиальные изменения могут поначалу вызывать затруднения у пользователей, привыкших к SMS 2003, новый подход определенно стоит того. Удачной работы!

Стив Рачуи (Steve Rachui) – инженер по улучшению поддержки управляемости в группе службы поддержки продукции корпорации Майкрософт. Он занимался поддержкой SMS начиная с версии 1.2. Связаться со Стивом можно по адресу steverac@microsoft.com.


 Связь: Пограничные транспортные серверы Exchange в корпорации Майкрософт
Связь Кэй Анкрот (Kay Unkroth)

Пограничные транспортные серверы Exchange в корпорации Майкрософт
Краткий обзор:
  • Роль пограничного транспортного сервера Exchange
  • Настройка лаборатории тестирования
  • Агенты транспорта и события
  • Внутренняя структура агентов
Загрузить исходный код для этой статьи: ExchangeEdge2007_10.exe (354KB)

В течение среднего рабочего дня в корпорации Майкрософт совершается приблизительно 13 миллионов попыток передачи сообщений из Интернета — из них более 10,5 миллионов блокируются как ненадежные. В критических
ситуациях, например во время атак нежелательной почты или вирусной эпидемии в Интернете, эта цифра может резко вырасти, превысив 90 миллионов. Безусловно, эти данные относятся к корпорации Майкрософт, но аферы, распространение нежелательной почты, фишинг, вирусы, разносимые электронной почтой, сбор информации о каталогах, распределенные атаки типа «отказ в обслуживании» (DDoS) и другие проблемы подобного свойства возникают не только в Майкрософт. Каким способом при столкновении с этими проблемами обеспечить доставку пользователям всех надежных сообщений, не допуская проникновения в среду обмена сообщениями потока ненадежного и вредоносного содержимого?
Один из способов обеспечения надежной защиты среды обмена сообщениями состоит в развертывании пограничных транспортных серверов Exchange Server 2007 и приложения Forefront Security для Exchange Server в пограничной сети, находящейся между Интернетом и рабочей средой. При этом в пограничной сети размещается организованная группа, включающая в себя более 10 агентов пограничного транспортного сервера, обеспечивающая защиту рабочих систем и пользователей. Очевидна значимость блокировки нежелательного содержимого на самых ранних, по возможности, этапах. В идеале, учитывая ту нагрузку, которая в противном случае ложится на вашу среду обмена сообщениями во время устранения критической ситуации, такую блокировку следует выполнять даже до момента доставки содержимого на ваши серверы. Однако задача защиты среды обмена сообщениями не сводится к простой блокировке сообщений.
Данная статья является первой частью работы, посвященной обсуждению архитектуры и важнейших функций агентов, имеющихся в среде Exchange Server 2007 и приложении Forefront Security для Exchange Server, обеспечивающих защиту от нежелательной почты и вирусов. Чтобы сделать это обсуждение реалистичным и практичным, в первой статье будет показано, как создать лабораторию тестирования, полностью воспроизводящую проект по защите среды обмена сообщениями, используемый Майкрософт в своей корпоративной рабочей среде. Затем архитектура пограничного транспортного сервера среды Exchange Server 2007 будет рассмотрена более подробно.
На протяжении этой статьи будут активно использоваться сценарии и пакетные файлы, предназначенные для автоматизации наиболее важных задач настройки. В эти файлы включены комментарии с объяснениями конкретных выполняемых действий. Сценарии находятся в файлах для загрузки, размещенных на веб-узле журнала TechNet Magazine по адресу technetmagazine.com/code07.aspx.

Топология пограничных транспортных серверов
На рис. 1 показана структура пограничного транспортного сервера, реализованная в корпоративной рабочей среде отделом ИТ корпорации Майкрософт. Прежде чем начать рассмотрение архитектуры пограничного транспортного сервера, хочется обратить ваше внимание на некоторые крайне интересные особенности его структуры. Тем, кого интересуют все детали реализации, рекомендую ознакомиться с документом «Выставка ИТ», ссылка на который имеется на боковой панели «Материалы по Exchange».
Рис. 1 Топология пограничных транспортных серверов в корпорации Майкрософт
Рис. 1 Топология пограничных транспортных серверов в корпорации Майкрософт
Анализируя рис. 1, обратите внимание на то, что в корпорации Майкрософт топология пограничных транспортных серверов в полном объеме обеспечена резервированием. Нет ни одного места, где существовала бы хотя бы одна точка отказа. Для балансировки нагрузки отдел ИТ Майкрософт использует циклический перебор DNS извне и соединители обмена сообщениями с несколькими плацдармами — внутри. Также стоит отметить тот факт, что на всех транспортных серверах (транспортный сервер-концентратор и пограничный транспортный сервер) с целью поиска вирусов выполняется приложение Forefront Security для Exchange Server. Это позволяет отделу ИТ Майкрософт проверять все входящие, исходящие и внутренние сообщения, как только они достигают транспортного сервера в топологии маршрутизации сообщений.
Еще одной важной особенностью проекта, относящейся к безопасности, является то, что пограничные транспортные серверы не являются частью корпоративной среды Active Directory®. Фактически, нет необходимости развертывать пограничные транспортные серверы в каком-либо из лесов Active Directory. Однако для поддержания согласованности инфраструктуры управления, применения общего набора политик и поддержки режима единого входа отдел ИТ Майкрософт развертывает все пограничные транспортные серверы в лесе наружной сети, отделенной от рабочей среды.
В конечном счете, ясно видно, что все сообщения из Интернета достигают корпорации Майкрософт через пограничные транспортные серверы, установленные в Северной Америке. Пограничные транспортные серверы, находящиеся в Дублине и Сингапуре, обрабатывают только исходящие сообщения. Преимущество концентрирования всего входящего трафика на пограничных транспортных серверах в Северной Америке заключается в централизации средств управления безопасностью и борьбы с нежелательной почтой и одновременном избавлении от передачи исходящих сообщений из больших региональных центров данных по внутренней магистрали системы обмена сообщениями.
Топологию пограничных транспортных серверов разработал Омеш Десаи (Omesh Desai), специалист отдела ИТ Майкрософт. На мой вопрос о наиболее важных особенностях проекта Омеш ответил следующее. «Встроенные в Exchange возможности борьбы с нежелательной почтой и вирусами успешно используются в нашем проекте пограничных транспортных серверов для защиты системы обмена сообщениями на нескольких уровнях магистрали обмена сообщениями. Безопасность внешней границы системы обмена сообщениями является первоочередной задачей, но для нас важна также простая модель администрирования и управления. Пограничный транспортный сервер позволяет повысить безопасность за счет более надежных конфигураций брандмауэров при одновременном увеличении точности фильтрации нежелательной почты с помощью служб репутации IP, автоматических обновлений фильтров содержимого, объединения списков надежных отправителей и проверки почтовой марки сообщения электронной почты. По умолчанию выполняется шифрование всех операций взаимодействия серверов, и, по возможности, шифруются также операции взаимодействия с внешними адресатами.
«На наших пограничных транспортных серверах используются два двухъядерных 64-разрядных процессора и восемь гигабайт памяти. При наличии шести таких серверов, нагрузка которых балансируется для двух центров данных, у нас достаточно ресурсов для противостояния даже большим всплескам поступления сообщений, например во время вирусной эпидемии в Интернете».

Лаборатория тестирования пограничного транспортного сервера
Установка лаборатории тестирования
Поскольку наилучшей методикой является использование несуществующих имен доменов и частных IP-адресов, я использую AdventureWorks.com и IP-адреса из диапазонов 192.168.xxx.0-24. Резервные системы или массивы брандмауэров отсутствуют, потому что не проводится тестирование балансировки нагрузки или отказоустойчивости. (И, безусловно, реальные системы брандмауэров, используемые отделом ИТ корпорации Майкрософт, не обсуждаются по соображениям безопасности.) В любом случае, такие подробности не имеют значения для данной среды тестирования.
В моей среде тестирования используется среда ISA Server 2006, поскольку она, вероятно, одна из наиболее распространенных систем брандмауэров, используемых совместно с Exchange Server 2007. Запуская ISA Server 2006 как на внутреннем, так и на внешнем брандмауэре, можно поддерживать сложность среды тестирования на среднем уровне, но для рабочих систем я все-таки рекомендую использовать разные системы брандмауэров, являющихся внешними и внутренними, чтобы повысить безопасность. Не разворачиваются политики безопасности IP (IPsec), а также не выполняется подготовка среды для протокола TLS (Transport Layer Security), поскольку эти темы выходят за рамки данной статьи.
Однако используются виртуальные компьютеры и 32-разрядное пробное программное обеспечение, которое можно загрузить с веб-узла Майкрософт. Майкрософт не поддерживает 32-разрядную версию Exchange Server 2007 в рабочих средах, но это не мешает использовать его в среде тестирования.
Везде, где это возможно, моя лаборатория тестирования опирается на настройки по умолчанию. До момента запуска установки Exchange Server 2007 и подписки пограничного транспортного сервера на рабочую среду особое внимание необходимо уделить только настройке IP, брандмауэров и зон DNS. Подробные сведения о настройке IP находятся в файле лаборатории тестирования — IP Configuration.xls, входящем в прилагаемые файлы для загрузки. Если использовать одинаковые назначения IP-адресов, можно быстро настроить внешний брандмауэр, названный ISA01, запустив сценарий ISA01_Firewall_Policies.vbs непосредственно на компьютере ISA01, а для внутреннего брандмауэра (ISA02) использовать сценарий ISA02_Firewall_Policies.vbs. В прилагаемые файлы для загрузки включены также пакетные файлы для настройки серверов DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat и AD02_DNS_Config.bat). Поскольку в этих пакетных файлах используется средство командной строки для DNS (dnscmd.exe), потребуется установить средства поддержки Windows; в противном случае придется вручную создавать записи DNS с помощью консоли DNS.
Для устранения какого-либо влияния со стороны существующих сред моя лаборатория тестирования не подключена к Интернету. Такая изоляция является разумной предосторожностью. Это приводит к тому, что все загрузки обновлений сигнатур, репутаций IP и обновлений фильтра содержимого завершаются аварийно, но для целей тестирования это не так важно. Чтобы устранить сообщения об ошибках, перейдите в консоли администратора Forefront Server Security в режим «Scanner Updates» (обновления системы проверки), установите однократное обновление для всех механизмов проверки и укажите прошедшую дату.

Разумным подходом к изучению этих функций в рабочем режиме является создание среды тестирования — здравый смысл подсказывает, что в целях тестирования никогда нельзя использовать рабочую систему. Для выполнения ролей сервера почтовых ящиков, клиентского доступа и транспортного сервера-концентратора потребуется как минимум один сервер, на котором работает Exchange Server 2007. Для роли пограничного транспортного сервера понадобится второй сервер Exchange. Если все агенты транспорта разворачиваются на сервере с несколькими ролями посредством запуска сценария Install-AntispamAgents.ps1 (он находится на транспортных серверах-концентраторах в папке %ProgramFiles%\Microsoft\Exchange Server\Scripts), установку пограничного транспортного сервера можно пропустить. Но такой подход вряд ли будет напоминать развертывание, выполненное отделом ИТ в Майкрософт. Для получения реалистичной лаборатории тестирования необходимо включить еще несколько серверов. На рис. 2 показана среда тестирования, которую я использовал при работе над этой статьей. Более подробная схема входит в прилагаемые файлы для загрузки. Дополнительные сведения о настройке лаборатории приведены на боковой панели «Установка лаборатории тестирования».
Рис. 2 Среда тестирования пограничного транспортного сервера
Рис. 2 Среда тестирования пограничного транспортного сервера
Во время подписки пограничного транспортного сервера и настройки соответствующих соединителей отдел ИТ Майкрософт удаляет все соединители по умолчанию, после чего переходит к созданию четырех соединителей отправки для эффективного взаимодействия с узлами SMTP разных типов и внутренними транспортными серверами-концентраторами. Первый соединитель отправки представляет собой подключатель к Интернету для всех адресов назначения, не удовлетворяющих специальным определениям пространства адресов.
Второй соединитель отправки является подключателем к Интернету с подробными определениями пространства адресов для известных адресов назначения, не поддерживающих протокол Extended SMTP (домены HELO). Устанавливая значение $true для параметра ForceHELO данного соединителя, отдел ИТ Майкрософт при установлении подключений SMTP избавляется от ненужной последовательности EHLO, Failure Response 500, HELO.
Третий соединитель отправки является подключателем к Интернету с подробными определениями пространства адресов для партнеров и других удаленных доменов, поддерживающих TLS, для безопасного взаимодействия через шифрованные подключения (домены TLS). Для параметра RequireTLS данного соединителя установлено значение $true.
Четвертый соединитель отправки является соединителем приема, предназначенным для передачи полученных из Интернета сообщений на транспортные серверы-концентраторы корпоративной среды. Более подробные сведения, относящиеся к настройке пограничного транспортного сервера, также приведены в документе «Выставка ИТ», ссылка на который находится на боковой панели «Материалы по Exchange» в конце этой статьи.
Применяя для лаборатории тестирования топологию соединителей в стиле отдела ИТ Майкрософт, я основывался на процедуре, использующей сценарии, созданные Омешем для внутреннего использования в отделе. По соображениям безопасности я радикально изменил и укоротил отдельные команды, но результирующая топология соединителей все еще соответствует топологии, используемой в отделе ИТ Майкрософт. Процедура состоит из следующих этапов.
  1. На многоролевом сервере Exchange (HUB-MBX-01) и пограничном транспортном сервере (EDGE01) удаляются соединители по умолчанию.
  2. На HUB-MBX-01 создается новый соединитель в результате выполнения сценария HUB-MBX-01_recv_connector.ps1, который находится в файлах загрузки, сопровождающих эту статью.
  3. На EDGE01 в результате выполнения сценария EDGE01_recv_connector.ps1 создаются два новых соединителя, обеспечивающие связь для обмена сообщениями с внутренней и внешней средой.
  4. На EDGE01 создается файл подписки в результате выполнения следующей команды.
    New-EdgeSubscription -FileName
    "c:\subscriptionfile.xml"
Затем полученный файл подписки копируется в корневую папку (c:\subscriptionfile.xml) транспортного сервера-концентратора.
5. Необходимо убедиться в том, что c:\subscriptionfile.xml — путь к файлу подписки на HUB-MBX-01, после чего запустить сценарий HUB-MBX-01_complete_subscription.ps1. В этом сценарии выполняется импорт файла подписки для синхронизации пограничных серверов без автоматического создания соединителя отправки, создаются соединители отправки для Интернета и внутренней связи, и результирующая настройка реплицируется на пограничный транспортный сервер посредством синхронизации пограничных серверов.
6. Проверка настройки осуществляется посредством отправки из узла Интернета тестовых сообщений с адресов Contoso.User@contoso.com и Fabrikam.User@fabrikam.com по адресу Administrator@adventureworks.com и ответа на полученные сообщения для проверки работы передачи входящих и исходящих сообщений.
Рекомендуется открыть конкретные файлы сценариев в приложении «Блокнот» и проанализировать командлеты и параметры, используемые этими сценариями для выполнения настройки. Подробные сведения об этих командлетах и параметрах имеется в Интернете в документации по программному продукту для Exchange Server 2007.

Архитектура пограничного транспортного сервера
Перейдем теперь к агентам пограничного транспортного сервера, ожидающим возможности сказать кому-нибудь HELO или EHLO с того момента, как была установлена роль пограничного транспортного сервера. Если на пограничном транспортном сервере выполняется командлет Get-TransportAgent, должны отобразиться 11 записей, перечисленных на рис. 3. По умолчанию все агенты активированы посредством определенных параметров для обеспечения защиты системы обмена сообщениями.
Figure 3 Агенты транспорта (Close Figure 3)

Агенты приема SMTP
Агент фильтра подключений
Входящий агент перезаписи адресов
Агент пограничных правил
Агент фильтра содержимого
Агент идентификаторов отправителей
Агент фильтра отправителей
Агент фильтра получателей
Агент анализа протокола
Агент фильтрации вложений
Агенты маршрутизации
Исходящий агент перезаписи адресов
Агент маршрутизации FSE
В командлете Get-TransportAgent и на рис. 3 агенты перечислены в порядке их приоритетов, но это не тот порядок, в котором данные агенты выполняют свою работу. Последовательность, в которой они работают, зависит главным образом от последовательности событий приема SMTP и маршрутизации событий, для которых данные агенты зарегистрированы. Чтобы понять, как агенты и события сопоставляются друг другу, рассмотрим схему, показанную на рис. 4, которая поясняет, каким образом агенты транспорта включаются в архитектуру пограничного транспортного сервера.
Рис. 4 Агенты транспорта в архитектуре пограничного транспортного сервера
Рис. 4 Агенты транспорта в архитектуре пограничного транспортного сервера
Транспортные события создаются на различных этапах обработки сообщений с целью вызова дополнительных модулей для фильтрации нежелательной почты, поиска вирусов и выполнения других задач. В такой слабосвязанной и расширяемой структуре роль источника событий берет на себя процесс пограничного транспортного сервера (EdgeTransport.exe). Обработчики событий, или, другими словами, агенты транспорта, управляются объектами-делегатами на базе Microsoft® .NET Framework 2.0 и зарегистрированы вместе с источником события для приема уведомлений обратного вызова.
На рис. 5 показаны регистрации всех агентов, установленных на пограничном транспортном сервере с приложением Forefront Security. Возможно, с этими регистрациями довольно трудно разобраться из-за большого числа регистраций агентов, но отчаиваться не следует. Выполнив на пограничном транспортном сервере команду Get-TransportPipeline | Format-List, можно в более удобном виде проанализировать регистрации для каждого отдельного транспортного события. Достаточно убедиться в том, что работает транспортная служба Microsoft Exchange (MSExchangeTransport.exe) и что с момента последнего перезапуска службы по крайней мере одно сообщение было отправлено через пограничный транспортный сервер. В результате выясняется, что для события одного типа можно зарегистрировать несколько агентов и что для одного агента можно зарегистрировать несколько событий. Регистрации событий зависят от требований обработки, предъявляемым соответствующим агентом.
Рис. 5 Регистрации событий для агентов транспорта
Рис. 5 Регистрации событий для агентов транспорта
Одним из наиболее важных событий является событие маршрутизации OnSubmittedMessage, возникающее при достижении сообщением очереди передачи. Все сообщения должны пройти через эту очередь независимо от пути их поступления — через SMTP, файловую систему или любой другой механизм. Классификатор является основным компонентом архитектуры пограничного транспортного сервера, отвечающим за разрешение получателей, разветвление сообщений и создание уведомлений о состоянии доставки (DSN). Событие OnSubmittedMessage, таким образом, является идеальным вариантом для регистрации агентов, которые должны обрабатывать все принимаемые сообщения. Агент маршрутизации FSE является компонентом приложения Forefront Security, зарегистрированным для события OnSubmittedMessage с целью передачи всех принимаемых сообщений обработчикам, выполняющим поиск вирусов. Поскольку агент маршрутизации FSE зарегистрирован для события OnSubmittedMessage, ни одно сообщение не минует процедуру поиска вирусов.
Почему же в таком случае не зарегистрировать все агенты для события OnSubmittedMessage и не считать задачу выполненной? По той причине, что нежелательные сообщения требуется блокировать на как можно более раннем этапе — до того, как сервер подтвердит успешную доставку. В противном случае вашим серверам, возможно, придется обрабатывать 90 миллионов нежелательных сообщений, поступающих во время атак нежелательной почты или вирусных атак, и создавать 90 миллионов отчетов о невыполнении доставки (NDR), что, в свою очередь, может создать серьезную угрозу для безобидных наблюдателей. Атаки нежелательной почты и вирусные атаки почти всегда используют подложные данные об отправителе. Отправка миллионов отчетов NDR получателям, не создававшим исходных сообщений, является не только бесполезной тратой ваших ресурсов и ресурсов предприятий получателей — таким образом пользователям-злоумышленникам предоставляется возможность запускать атаки с отправкой огромного числа почтовых сообщений и атаки DDoS. Важно вовремя остановить злоумышленников-отправителей, чтобы защитить себя и других.
Для эффективной блокировки сообщений агент транспорта должен прервать диалог по протоколу SMTP до того, как ваш сервер подтвердит успешное получение данных посредством кода состояния 250. В соответствии с принципом хранения и пересылки протокола SMTP ваш сервер может безопасно отбросить любые полученные данные, не создавая отчеты NDR, если доставка сообщения не была подтверждена. Эту задачу могут выполнить агенты приема SMTP. Они взаимодействуют с сеансом SMTP, поскольку транспортный конвейер вызывает эти агенты на основе событий приема SMTP, когда удаленный узел соединяется с сервером; устанавливает сеанс SMTP; передает глаголы SMTP; отправляет сообщения и завершает соединение. (События приема SMTP, связанные с каждым их этапов, перечислены на рис. 6.) Вследствие способности отклонять сообщения до момента доставки и отключения удаленных узлов SMTP все агенты Exchange Server 2007, противостоящие нежелательной почте, реализуются в качестве агентов приема SMTP.
Figure 6 События сеансов SMTP (Close Figure 6)

Действие | Связанные события
Подключение к серверу | OnConnectEvent
Создание сеанса SMTP | OnHeloCommand, OnEhloCommand, OnAuthCommand, OnEndOfAuthentication
Передача глаголов SMTP | OnMailCommand, OnRcptCommand, OnDataCommand, OnNoopCommand, OnHelpCommand
Передача сообщений | OnEndOfHeaders, OnEndOfData
Отклонение команды или сообщения | OnReject
Сброс подключения | OnRsetCommand
Завершение подключения | OnDisconnect
Важно осознавать разницу между агентами приема SMTP и агентами маршрутизации в том, что касается их контекстов обработки. В то время как агенты маршрутизации имеют полный доступ к свойствам сообщений, агенты приема SMTP более чувствительны к контексту, поскольку эти агенты взаимодействуют с сеансом SMTP. Например, фильтр нежелательной почты не может действовать в соответствии со свойствами сообщения до тех пор, пока удаленный узел действительно не передал сообщение. Следовательно, регистрация агента важна для правильного события приема SMTP. Более глубокие пояснения приведены на боковой панели «Разработка агента транспорта».

Материалы по Exchange
  • Пограничный транспортный сервер Microsoft Exchange Server 2007 и защита системы обмена сообщениями (технический документ «Выставка отдела ИТ Майкрософт»)
  • Центр сценариев Windows PowerShell
  • Exchange Server 2007 TechCenter
  • Блог группы Microsoft Exchange «You Had Me From EHLO»

Ждите продолжения...
Сделаем перерыв перед тем как углубиться в архитектуру транспорта и тестовые ситуации. Было рассмотрено множество вопросов, начиная от развертывания пограничных транспортных серверов в стиле отдела ИТ Майкрософт и до внутренних событий, запускаемых в транспортном конвейере во время обработки сообщений. В следующем выпуске этой серии из двух частей будет продолжен анализ поведения агентов пограничного транспортного сервера в нескольких любопытных тестовых ситуациях.
Тем временем я рекомендую загрузить 90-дневную пробную версию Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) и поступить в соответствии с рекомендациями Стива, относящимися к компиляции и установке примеров агентов в вашей среде тестирования. Даже не являясь разработчиком, вы согласитесь с тем, что эти задачи выполняются крайне просто. Учитывая то, насколько удобно в среде Exchange Server 2007 разрабатывать такие компоненты с помощью Visual Studio 2005, меня не удивит рост числа бизнес-приложений, основывающихся на пользовательских агентах.

Кэй Анкрот (Kay Unkroth) — предприниматель, который более 15 лет работает в качестве инженера по технической поддержке, специалиста по разработке систем, консультанта, инструктора и пишет работы, посвященные главным образом серверным технологиям Майкрософт. Кроме этого, Кэй является соучредителем и председателем корпорации Biblioso — эта компания занимается управляемой документацией и услугами по локализации.


 SQL Server: Оптимизация производительности ЦП SQL Server
SQL Server Зак Нихтер (Zach Nichter)

Оптимизация производительности ЦП SQL Server
Краткий обзор:
  • Устранение проблем производительности базы данных
  • Проверка причин, связанных с оборудованием
  • Использование системного монитора для отслеживания узких мест базы данных
  • Оценка производительности выполнения запросов

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

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

Основные моменты
Технология гиперпоточности
На технологии гиперпоточности стоит остановиться из-за того, как она влияет на SQL Server. Технология гиперпоточности фактически предоставляет операционной системе для одного физического процессора два логических процессора. По сути, технология гиперпоточности арендует время физических процессоров для полного использования возможностей каждого процессора. На веб-узле Intel (intel.com/technology/platform-technology/hyper-threading/index.htm) представлено гораздо более подробное описание работы технологии гиперпоточности.
В системах SQL Server DBMS фактически обрабатывает собственные чрезвычайно эффективные очереди и потоки для операционной системы, поэтому в системах с уже существующей высокой загрузкой процессоров технология гиперпоточности только еще больше перегружает физические ЦП. Когда SQL Server осуществляет постановку в очередь нескольких запросов для работы с несколькими планировщиками, операционной системе приходится переключать контекст потоков команд для обеспечения соответствия выполняемым запросам, даже если два логических процессора принадлежат одному физическому процессору. Если показатель «Контекстных переключений/сек» превышает 5000 для одного физического процессора, следует серьезно рассмотреть вопрос об отключении гиперпоточности в системе и повторном тестировании производительности.
Только в очень редких случаях приложения с высокой загрузкой процессора в SQL Server могут эффективно использовать гиперпоточность. Перед реализацией изменений в рабочих системах необходимо всегда проверять приложения в SQL Server с включенной и выключенной гиперпоточностью.

Производительность мощного двухъядерного процессора всегда будет превосходить производительность ОЗУ компьютера, скорость которого в свою очередь будет больше скорости подключенного запоминающего устройства. Пропускная способность хорошего процессора приблизительно в шесть раз превосходит пропускную способность лучшей современной памяти DDR2 и приблизительно в два раза превосходит пропускную способность лучшей памяти DDR3. Пропускная способность обычной памяти более чем в 10 раз превышает пропускную способность самых быстрых оптоволоконных приводов. В свою очередь, жесткие диски могут выполнять только ограниченное число операций ввода/вывода в секунду (IOPS), это значение всецело зависит от количества операций поиска в секунду, которое может выполнять привод. Справедливости ради надо сказать, что для удовлетворения всех потребностей в хранении систем баз данных предприятий обычно используется несколько устройств хранения. Сегодня в большинстве установок используются сети хранилищ данных (SAN) на серверах баз данных предприятий или группы RAID большего размера, которые могут минимизировать или устранить проблему процессора дискового ввода-вывода. Важно помнить, что независимо от особенностей установки системы узкие места со стороны дисков и памяти могут повлиять на производительность процессоров.
Из-за различий в скорости ввода-вывода получение данных с диска намного дороже, чем получение данных из памяти. Размер страницы данных в SQL Server – 8 КБ. Блок в SQL Server состоит из восьми страниц размером 8 КБ каждая и соответственно имеет размер 64 КБ. Это важно понимать, поскольку когда SQL Server запрашивает определенную страницу данных с диска, выполняется получение всего блока, в который входит страница данных, а не только этой определенной страницы. Существует ряд причин, делающих это наиболее эффективным для SQL Server, но в данной статье я не будут рассматривать этот вопрос подробно. Получение страницы данных, уже кэшированной из буферного пула, с максимальной производительностью выполняется в течение половины миллисекунды; получение одного блока с диска в оптимальной среде занимает от 2 до 4 миллисекунд. Обычно чтение хорошо работающей исправной дисковой подсистемы занимает от 4 до 10 мс. Получение страницы данных из памяти обычно выполняется от 4 до 20 раз быстрее, чем получение страницы данных с диска.
Когда SQL Server запрашивает страницу данных, он выполняет поиск в буферном кэше в памяти, а затем в дисковой подсистеме. Найдя страницу данных в буферном пуле, процессор получит данные и выполнит необходимые операции. Это называется ошибкой страницы ОЗУ. Ошибки страниц ОЗУ идеальны для SQL Server, поскольку для использования данных, полученных в качестве части запроса, они должны находиться в буферном кэше. Страница данных, не найденная в буферном кэше, должна быть получена из дисковой подсистемы сервера. Необходимость получения операционной системой страницы данных диска называется ошибкой страницы физической памяти.
При согласовании производительности памяти, дисков и ЦП объективно оценить все компоненты помогает общий знаменатель: пропускная способность. Говоря ненаучно, пропускная способность – это максимальный объем данных, который может передавать конечный канал.

Путь 1. Производительность системы
Существует всего несколько способов определения наличия узких мест ЦП на сервере и не очень много возможных причин высокой загрузки процессора. Некоторые из этих проблем можно отследить с помощью системного монитора или сходного средства наблюдения за системой, другие же проблемы можно отследить с помощью профилировщика SQL или сходных средств. Другой способ заключается в использовании команд SQL в Query Analyzer или SQL Server Management Studio (SSMS).
При оценке производительности системы я использую подход «Начните широко, затем анализируйте подробно». Очевидно, исследование проблемных мест возможно только после их определения. После оценки общего использования ЦП с помощью специальной программы, например системного монитора, ее можно использовать для просмотра нескольких очень простых и понятных счетчиков производительности.
Одним из самых известных счетчиков производительности является счетчик «% загруженности процессора»; во время работы системного монитора этот счетчик выделяется после открытия окна «Add Counter» (Добавление счетчика). Счетчик «% загруженности процессора» отображает время, в течение которого процессоры остаются занятыми при выполнении операций. Как правило, загруженность процессоров считается высокой, когда это значение составляет 80 или более процентов в течение большей части времени работы с максимальной загрузкой. Иногда значение может внезапно повышаться до 100 процентов, даже если сервер работает с загрузкой менее 80 процентов, но это не является неполадкой.
Другим счетчиком, который необходимо использовать, является «Длина очереди процессора», который находится в объекте «Система» системного монитора. Счетчик «Длина очереди процессора» показывает количество потоков, ожидающих выполнения на процессоре. Управление работой SQL Server осуществляется с помощью планировщиков в механизме СУБД, где сервер помещает в очередь и обрабатывает собственные запросы. Поскольку работа SQL Server управляет им самим, он использует только один поток ЦП для каждого логического процессора. Это означает, что в очереди процессора системы, предназначенной для SQL Server, должно находиться минимальное количество потоков. Обычно количество потоков на выделенном сервере SQL Server в пять раз меньше количества физических процессоров, но я считаю, что если количество потоков в два раза превышает количество физических процессоров, это уже является проблемой. На серверах, где кроме СУБД используются и другие приложения, этот счетчик необходимо использовать вместе со счетчиками производительности «% загруженности процессора» и «Контекстных переключений/сек» (переключения контекста будут рассмотрены позже) для определения необходимости перемещения СУБД или приложений на другой сервер.
При возникновении очереди процессора и высокой загрузке ЦП я использую счетчики «Compilations/sec» (Компиляций/с) и «Re-Compilations/sec» (Повторных компиляций/с) объекта производительности «SQL Server: статистика SQL» (см. рис. 1). Компиляция и повторная компиляция планов запросов влияет на загрузку ЦП системы. Значения повторных компиляций должны быть около нуля, но необходимо проверить потоки системы, чтобы определить обычное поведение сервера и допустимое количество компиляций. Не всегда удается избежать повторных компиляций, но можно оптимизировать запросы и хранимые процедуры, чтобы свести к минимуму количество повторных компиляций и использований планов запросов. Сравните эти значения с фактическими поступающими в систему инструкциями SQL с помощью счетчика «Пакетных запросов/с», который также находится в объекте «SQL Server: статистика SQL». Если компиляции и повторные компиляции составляют значительный процент поступающих в систему запросов пакетов, это место необходимо проверить. Иногда разработчики SQL могут не понимать, как и почему их код может влиять на эти типы проблем системных ресурсов. Далее в этой статье я приведу ссылки, которые помогут свести к минимуму действия такого типа.
Рис. 1 Выбор счетчиков для отслеживания
Рис. 1 Выбор счетчиков для отслеживания
В системном мониторе найдите счетчик производительности «Контекстных переключений/сек» (см. рис. 2). Этот счетчик указывает количество получений потоков из планировщиков операционной системы (не из планировщиков SQL) для выполнения операций для других потоков в состоянии ожидания. Часто переключения контекста происходят значительно чаще в системах база данных, использующихся совместно с другими приложениями, например IIS или компонентами сервера приложений сторонних производителей. Для счетчика «Контекстных переключений/сек» я использую пороговое значение приблизительно в 5000 раз большее количества процессоров в сервере. Это значение также может быть высоким в системах с включенной гиперпоточностью и невысокой загрузкой ЦП. Если пороговые значения загрузки ЦП и переключений контекста регулярно превышаются, это говорит о наличии узкого места, связанного с ЦП. Если такие ситуации возникают регулярно, и ваша система устарела, необходимо запланировать приобретение дополнительных или более быстрых процессоров. Дополнительные сведения приведены на боковой панели «Гиперпоточность».
Figure 2 Используемые счетчики производительности (Close Figure 2)

Счетчик производительности | Объект счетчика | Пороговое значение | Примечания
«% используемого времени процессора» | Процессор | > 80% | Возможные причины включают недостаток памяти, редкое повторное использование плана запроса, неоптимизированные запросы.
«Контекстных переключений/сек» | Система | > 5000 x (число процессоров) | Возможные причины включают другие приложения на сервере, несколько экземпляров SQL Server на одно сервере, включение технологии hyper-threading.
«Длина очереди процессора» | Система | > 5 x (число процессоров) | Возможные причины включают другие приложения на сервере, большое количество компиляций или перекомпиляций, несколько экземпляров SQL Server на одно сервере.
«Compilations/sec» (Компиляций/с) | SQLServer:статистика SQL | Тенденция | Сравнение со счетчиком «Запросов пакетов/с»
«Re-Compilations/sec» (Перекомпиляций/с) | SQLServer:статистика SQL | Тенденция | Сравнение со счетчиком «Запросов пакетов/с»
«Запросов пакетов/с» | SQLServer:статистика SQL | Тенденция | Сравнение с количеством компиляций и перекомпиляций в секунду.
«Ожидаемый срок жизни страницы» | SQLServer:диспетчер буферов | < 300 | Возможная нехватка памяти.
«Отложенных записей/с» | SQLServer:диспетчер буферов | Тенденция | Возможный сброс большого кэша данных или нехватка памяти.
«Checkpoints/sec» (Контрольных точек/с) | SQLServer:диспетчер буферов | Тенденция | Оценка контрольных точек с помощью счетчиков «Ожидаемый срок жизни страницы» и «Отложенных записей/с».
Коэффициент попадания в кэш: планы SQL | SQLServer:кэш планов | < 70% | Указывает на редкое повторное использование плана.
Коэффициент попадания в буферный кэш | SQLServer:диспетчер буферов | < 97% | Возможная нехватка памяти.
Модуль отложенной записи SQL Server (как он называется в SQL Server 2000) или монитор ресурсов (как он называется в SQL Server 2005) – это другая область для наблюдения при высокой загрузке ЦП. Сброс буфера и кэши процедур могут увеличивать процессорное время через поток ресурсов, называемый монитором ресурсов. Монитор ресурсов – это процесс SQL Server, определяющий страницы для сохранения и страницы для записи из буферного пула на диск. Всем страницам в буфере и кэшах процедур изначально присвоены стоимости, представляющие ресурсы, потребляемые при помещении этой страницы в кэш. Эти значения стоимостей уменьшаются при каждой проверке монитором ресурсов. При необходимости для запроса пространства в кэше страницы удаляются из памяти на основе присвоенных для всех страниц затрат; страницы с самыми низками значениями будут удаляться в первую очередь. Операции монитора ресурсов можно отследить с помощью счетчика производительности «Отложенных записей/с» объекта «SQL Server: диспетчер буферов» системного монитора. Необходимо отследить изменение этого значения, чтобы определить обычное для вашей системы пороговое значение. Обычно этот счетчик используется вместе со счетчиками «Ожидаемый срок жизни страницы» и «Checkpoints/sec» (Контрольных точек/с) для определения наличия нехватки памяти.
Счетчик «Ожидаемый срок жизни страницы» помогает определить наличие нехватки памяти. Счетчик «Ожидаемый срок жизни страницы» показывает длительность нахождения страницы данных в буферном кэше. Общепринятое в отрасли пороговое значение для этого счетчика – 300 секунд. Значение ниже среднего значения в 300 секунд, сохраняющееся в течение длительного времени, свидетельствует о том, что страницы данных удаляются из памяти слишком часто. Это увеличивает объем работы монитора ресурсов, что в свою очередь приводит к увеличению загрузки процессоров. Показания счетчика «Ожидаемый срок жизни страницы» должны оцениваться вместе с показаниями счетчика «Страниц контрольных точек/с». При возникновении в системе контрольной точки «грязные» страницы данных в буферном кэше записываются на диск, вызывая уменьшение значения счетчика «Ожидаемый срок жизни страницы». Процесс «Монитор ресурсов» – это механизм, фактически записывающий эти страницы на диск, поэтому при возникновении контрольных точек также увеличивается значение счетчика «Отложенных записей/с». Если значение счетчика «Ожидаемый срок жизни страницы» увеличивается сразу после выполнения контрольной точки, на это временное явление можно не обращать внимание. С другой стороны, при обнаружении того, что значение счетчика «Ожидаемый срок жизни страницы» регулярно находится ниже порогового значения, велика вероятность, что увеличение объема памяти приведет к устранению проблем и освобождению части ресурсов для ЦП. Все эти счетчики находятся в объекте производительности «SQL Server: диспетчер буферов».

Путь 2. Производительность запросов
Отслеживание SP
При трассировке приложения SQL Server имеет смысл ознакомиться с используемыми для трассировки хранимыми процедурами. Использование для трассировки графического интерфейса (SQL Server Profiler) может увеличить нагрузку на систему на 15 – 25 процентов. Использование для трассировки хранимых процедур может снизить процент увеличения нагрузки примерно наполовину.
Если мне известно о наличии в системе узких мест и необходимо определить текущие инструкции SQL, являющиеся причинами проблем на сервере, я выполняю приведенный ниже запрос. Этот запрос помогает получить представление об отдельных инструкциях и используемых ими в настоящий момент ресурсах, а также об инструкциях, которые необходимо изучить для повышения производительности. Дополнительные сведения о трассировках SQL приведены на веб-странице msdn2.microsoft.com/ms191006.aspx.
SELECT
    substring(text,qs.statement_start_offset/2
        ,(CASE
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2)
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

Планы запросов анализируются, оптимизируются, компилируются и помещаются в кэш процедур при отправке на SQL Server нового запроса. При каждой отправке серверу запроса выполняется проверка кэша процедур для попытки сопоставления плана запроса с запросом. При отсутствии плана запроса SQL Server создает новый план для запроса, что может быть дорогостоящей операцией.
Ниже приведены некоторые важные моменты, касающиеся оптимизации ЦП для T-SQL.
  • Повторное использование плана запроса
  • Уменьшение количества компиляций и повторных компиляций
  • Операции сортировки
  • Недопустимые соединения
  • Отсутствующие индексы
  • Просмотры таблиц/индексов
  • Использование функций в предложениях SELECT и WHERE
  • Многопоточные операции
Рассмотрим эти моменты. Обычно SQL Server получает данные из памяти и с диска; работа только с одной страницей данных встречается довольно редко. Гораздо чаше несколько частей приложения работают с записью, выполняют несколько небольших запросов или объединяют таблицы для создания общего представления соответствующих данных. В средах OLAP приложения могут получать миллионы строк из одной или двух таблиц, делая возможными консолидацию, накопление и суммирование данных для региональных ответов о продажах. В подобных случаях возврат данных может измеряться в миллисекундах, если данные находятся в памяти, а получение этих же данных с диска может длиться несколько минут.
Первый пример – это ситуация с большим количеством транзакций, в которой повторное использование плана зависит от приложения. Редкое повторное использование плана обуславливает большое число компиляций инструкций SQL, для чего требуется значительный объем процессорной обработки. Во втором примере высокая загрузка ресурсов может привести к чрезмерной активности системного ЦП, поскольку требуется постоянное удаление существующих данных из буферного кэша для освобождения пространства для новых страниц данных большого объема.
Рассмотрим систему с высокой интенсивностью транзакций, в которой инструкция SQL, подобная показанной ниже, выполняется 2000 раз в течение 15 минут для получения информации о транспортной упаковке. Гипотетически, без повторного использования плана запроса время выполнения одной инструкции составляет около 450 мс. При использовании этого же плана запроса после первого выполнения время выполнения последующего запроса может составлять около 2 мс, а общее время выполнения – около 5 секунд.
USE SHIPPING_DIST01;
SELECT
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;
Повторное использование плана запроса является критически важным для обеспечения оптимальной производительности в системах с высокой интенсивностью транзакций, что наиболее часто достигается с посредством параметризации запросов или хранимых процедур. Ниже приведено несколько отличных ресурсов с информацией о повторном использовании плана запроса.
  • Проблемы пакетной компиляции, перекомпиляции и кэширования плана в SQL Server 2005 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
  • Оптимизация хранимых процедур SQL Server для предотвращения перекомпиляций (sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
  • Перекомпиляция запроса в SQL Server 2000 (msdn2.microsoft.com/aa902682.aspx)
Полезным источником обширных сведений являются динамические административные представления (DMV). При высокой загрузке ЦП я использую несколько DMV для определения правильности использования ЦП.
Одним из используемых DMV является sys.dm_os_wait_stats, с помощью которого администраторам баз данных можно предоставить средства определения всех используемых сервером SQL функций и типов ресурсов, а также определить время ожидания системы, связанное с этим ресурсом. Счетчики в этом DMV являются накопительными. Это означает, что для получения ясного представления о ресурсах, которые могут влиять на различные области системы, после проверки данных на предмет наличия неразрешенных проблем прежде всего необходимо выполнить команду DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR). Динамическое административное представление sys.dm_os_wait_stats является эквивалентом команды проверки согласованности базы данных DBCC SQLPERF(WAITSTATS) в SQL Server 2000. Дополнительные сведения о различных типах ожидания приведены в электронной документации по SQL Server на веб-узле msdn2.microsoft.com/ ms179984.aspx.
Важно понимать, что обычно ожидания присутствуют даже при оптимальной работе системы. Необходимо только определить, влияют ли на ожидания ограничения со стороны ЦП. Время ожидания сигналов относительно общего времени ожидания должно быть как можно меньше. Время ожидания ресурса процессора определенным ресурсом может быть определено простым вычитанием времени ожидания сигнала из общего времени ожидания; это значение не должно превышать приблизительно 20 процентов общего времени ожидания.
Динамическое административное представление sys.dm_exec_sessions показывает все открытые сеансы на сервере SQL Server. Это DMV предоставляет обобщенное представление производительности всех сеансов и всех действий, выполненных в каждом сеансе с момента открытия. Сюда ходит общее время ожидания сеанса, общая загрузка ЦП, использование памяти и количество операций чтения и записи. DMV также предоставляет сведения о входе, времени входа, локальном компьютере и времени последнего запроса сеансом сервера SQL Server.
Динамическое административное представление the sys.dm_exec_sessions позволяет определять только активные сеансы, поэтому это одно из первых мест для поиска при высокой загрузке ЦП. Сначала необходимо выполнять проверку сеансов с большим числом ЦП. Определите приложение и пользователя, выполняющего работу, затем перейдите к углубленному анализу. Использование sys.dm_exec_sessions вместе с sys.dm_exec_requests может предоставить большое количество информации, доступной через хранимые процедуры sp_who и sp_who2. При объединении данных с функцией динамического управления sys.exec_sql_text в столбце sql_handle можно получить текущий выполняемый запрос сеанса. Во фрагменте кода на рис. 3 продемонстрировано объединение этих данных для получения сведений о том, что происходит на сервере.
Figure 3 Определение активности сервера (Close Figure 3)
SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC
Я считаю, что этот оператор позволяет определить приложения, которым необходимо уделить особое внимание. Когда я сравниваю ЦП, память, логические считывания, операции чтения и записи всех сеансов приложения и определяю, что загрузка ресурсов ЦП гораздо выше загрузки остальных ресурсов, я акцентирую внимание на этих операторах SQL.
Для отслеживания инструкций SQL по журналу для приложения я использую трассы SQL Server. Для этого можно использовать средство SQL Server Profiler или системные хранимые процедуры трассировки, чтобы оценить происходящее. (Дополнительные сведения по этой теме приведены на боковой панели «Трассировка SP».) В программе Profiler необходимо проверить операторы с высокой загрузкой ЦП, предупреждения хэширования и сортировки, промахи в кэше и другие красные флаги. Это позволяет сузить объекты проверки до определенных операторов SQL или периода времени с высокой загрузкой ресурсов. Программа Profiler позволяет отслеживать текст инструкций SQ, планы выполнения, загруженность ЦП, использование памяти, логические считывания, запись, кэширование планов запросов, перекомпиляции, извлечение планов запросов из кэша, промахи в кэше, просмотры таблиц и индексов, отсутствие статистики и множество других событий.
После сбора данных с помощью хранимых процедур sp_trace или средства SQL Server Profiler я обычно использую базу данных, заполненную уже полученными данными трассировки или данными, которые будут получены после установки для трассировки записи в базу данных. Заполнение базы данных уже полученными данными может быть выполнено с помощью системной функции SQL Server с названием fn_trace_getinfo. Преимущество этого подхода заключается в возможности запроса и сортировки данных несколькими способами для определения инструкций SQL, использующих большую часть времени ЦП или имеющих большее количество операций чтения, определения количество перекомпиляций и пр. Вот пример использования этой функции для загрузки таблицы с файлом трассировки Profile. По умолчанию все файлы для этой трассировки будут загружены в порядке их создания:
SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

Заключение
Как показано выше, высокая загрузка ЦП не обязательно свидетельствует о наличии узкого места, связанного с процессором. Высокая загрузка ЦП может также скрывать ряд других узких мест, связанных с приложениями или оборудованием. После определения высокой загрузки ЦП, несмотря на допустимые показания других счетчиков, можно начать поиск причины в системе и найти решение (будь то приобретение дополнительных процессоров или оптимизация кода SQL). Что бы вы ни делали, не сдавайтесь! Приведенные в данной статье советы, а также немного практических материалов и исследований делают оптимизацию загрузки ЦП в SQL Server достижимой задачей.

Зак Нихтер (Zach Nichter) — специалист по продукту SQL Server с более чем 10-летним опытом. Занимаясь поддержкой серверов SQL Server, выступал в роли администратора баз данных, ведущего сотрудника группы, менеджера и консультанта. В настоящее время Зак работает архитектором баз данных в компании Levi Strauss & Co. Он отвечает за производительность и архитектуру серверов SQL Server, а также занимается наблюдением за этими серверами и решает другие связанные с ними стратегические задачи. Кроме того, Зак ведет видеоблог, находящийся по адресу www.sqlcatch.com.


 От редактора: Лучшее — впереди
От редактора
Лучшее — впереди
Джошуа Хоффман (Joshua Hoffman)

Хотите верьте, хотите нет, но я собираюсь начать мою первую заметку редактора с воспоминаний. Уверяю вас, мне самому не очень-то нравится сразу использовать такой литературный прием — тем не менее, продолжим.
Летом 2005 года, когда 2 первых номера журнала TechNet Magazine были очень хорошо приняты публикой, пришло время наращивать производственные мощности и приступить к регулярной подаче отличного технического материала для специалистов по ИТ. Наш ответственный редактор Джошуа Трупин (Joshua Trupin) и наш собрат — технический редактор журнала MSDN Magazine Стивен Тауб (Stephen Toub) провели впечатляющую работу, организуя экспертов и планируя эти первые выпуски, однако они должны были вернуться к своей обычной работе.
Тогда я и присоединился к команде в качестве технического редактора. Меня поражала их уверенность во мне и дело, которое они делали. В конце концов, совсем непросто выпускать журнал. До приглашения в журнал я был специалистом по ИТ (настоящим компьютерным фанатом), проведя предыдущие четыре года в консультационной службе корпорации Майкрософт. Знаний об издательском деле у меня почти не было (вообще-то не было совсем). Список того, что мне нужно прочитать, был длиной в милю. Мне предстояло немедленно начать планировать решение трех задач. Мне нужно было познакомиться с членами команды, авторами, техническими рецензентами, деловыми партнерами и, конечно же, с читателями. Кроме всего этого, мне в письменном виде были поставлены крайние сроки, которые нельзя было передвигать (как можно себе представить, для человека, долго работающего в Майкрософт, было очень нелегко это понять).
Однако товарищи поддержали меня, приободрили и помогли. Трудно даже представить, насколько их помощь помогла моей работе. Захватывающей, сложной и приносящей глубокое удовлетворение сделали мою работу авторы, рецензенты, партнеры и вы — наши читатели! Иметь так много новых друзей — высокая честь для меня. Оглядываясь на два года назад, я горжусь тем, чего достигла наша команда. И, как новый главный редактор, я особенно вдохновлен тем, что ждет впереди.
Единственная задача этого журнала — обеспечивать успех специалистов по информационным технологиям в использовании продуктов и технологий Microsoft (поверьте, кроме всего прочего, от этого зависит наша зарплата). От вас мы узнаем и где мы действуем правильно, и где, что гораздо важнее, мы можем улучшить работу. Мы очень серьезно относимся к вашим оценкам. В течение следующих месяцев и лет журнал будет улучшаться, добавятся новые авторы и новые рубрики, новым содержимым и мультимедиа наполнится наша интерактивная платформа — и это все, надеюсь, поможет вам учиться так, как вам удобнее всего. Однако ни одна из этих целей не может быть достигнута без вашего активного участия. Расскажите нам, что вас устраивает, а что нет. На что нам нужно потратить время? Этот журнал для вас, так воспользуйтесь этим преимуществом. Напишите по адресу tnmag@microsoft.com и знайте, что ваш голос будет услышан. Джошуа Хоффман

Мы хотели бы поблагодарить следующих технических специалистов корпорации Майкрософт: Омеш Десаи (Omesh Desai), Раджа Ганджикунта (Raja Ganjikunta), Салем Хакани (Saleem Hakani), Джастин Холл (Justin Hall), Майкл Мурголо (Michael Murgolo), Джон Орефайс (John Orefice), Джим Труер (Jim Truher), Марк Умено (Marc Umeno), Джефф Уэтлауфер (Jeff Wettlaufer), Бак Вуди (Buck Woody) и Минсяо Жоу (Minxiao Zhou).


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

Большие возможности для создания сценариев
PowerShell Analyzer
www.pwershellanalyzer.com
Молва о Windows PowerShell™ идет широко, и на это есть причина. Язык сценариев нового поколения этой оболочки действительно стоит опробовать всем, кому такая возможность не представилась раньше. А те, кто перешел на Microsoft® Exchange 2007, быстро осознают, что новая среда управления Exchange построена на основе Windows PowerShell, делая возможным доступ ко всем функциям консоли управления Exchange из командной строки, что очень полезно для автоматизации повторяющихся задач. Увы, освоение синтаксиса и семантики требует некоторых усилий. Здесь-то и вступает в дело PowerShell Analyzer от компании ShellTools.
Это приложение по сути является средой IDE для написания и отладки сценариев Windows PowerShell. Но, в отличие от традиционного цикла «написание-компиляция-тестирование», данное приложение сохраняет стиль работы администратора за клавиатурой, давая интерактивность в режиме реального времени в рабочей среде PowerShell. PowerShell Analyzer позволяет как вводить команды построчно, так и создавать, править и запускать сценарии Windows PowerShell через редактор в нижней части пользовательского интерфейса. Оба варианта предоставляют базовые возможности автозавершения кода, что является серьезным подспорьем при работе с многочисленными параметрами командлетов. (Для тех, кто не знаком с Windows PowerShell: командлетами называются абстрактные, ориентированные на задачи параметризованные команды.)
В качестве дополнительного удобства PowerShell Analyzer предоставляет вкладку быстрого доступа, показывающую детальные описания, синтаксис, объяснение параметров и примеры для каждого командлета. Кроме того, есть также ссылки для поставщиков Windows PowerShell, встроенные файлы справки и краткие псевдонимы командлетов.
При запуске команд из Windows PowerShell возвращаются реальные объекты Microsoft .NET Framework, а не один лишь текст с результатами на экране. PowerShell Analyzer позволяет улавливать свойства возвращенных результатов и передавать их нескольким «визуализаторам». Эти визуализаторы позволяют взаимодействовать с объектами – например, предлагая разбор данных XML в форме дерева, или сортируемое и группируемое представление данных как таблицы, – а также создают набор различных диаграмм для визуального представления возвращаемого набора данных. Само собой, не все из этих функций доступны для каждой запускаемой команды или сценария, но в тех случаях, когда они применимы, они дают неплохой набор представлений данных, которые затем можно сохранить или экспортировать для повторного использования.
PowerShell Analyzer также позволяет работать с несколькими средами одновременно, легко переключаясь между задачами, а окно редактора предоставляет определение структуры кода и настраиваемые стили выделения кода, помогающие сделать сценарии более читаемыми.
В общем, если предстоит работа с Windows PowerShell, средство вроде PowerShell Analyzer сделает создание, правку и отладку сценариев, а также визуализацию данных намного проще.

Цена: 129 долларов США, напрямую, за лицензию для одного пользователя.
Представьте себе powershell
Представьте себе powershell

Дeфрагменация дисков
Disk Defrag от компании Auslogics
www.auslogics.com/disk-defrag
Чем активнее используется жесткий диск, тем более фрагментированными становятся файлы на нем. Создание и удаление файлов, установка и удаление приложений и даже создание временных дисковых кэшей и файлов вносят свою лепту в фрагментацию. Темп фрагментации может резко ускориться, если свободное пространство на диске ограничено, поскольку новые файлы будут раскидываться по доступным «дырам» в преимущественно заполненном пространстве. Все это ведет к понижению производительности системы.
Само собой, общеизвестно, что текущие версии Windows® включают встроенные средства дефрагментации. Но для тех, кто ищет специальное средство дефрагментации или после перехода на Windows Vista® желает вернуться к управлению и представлению интерфейса пользователя, предлагавшемуся прежними версиями средства дефрагментации, есть весьма интересная альтернатива: Disk Defrag от Auslogics.
Приложение Disk Defrag может работать под Windows XP, Windows 2000, Windows Server® 2003 и Windows Vista. И, как можно было от него ожидать, оно может дефрагментировать тома в форматах FAT16, FAT32 и NTFS. Приложение невелико по размеру и устанавливается за несколько щелчков.
Работать с приложением настолько же просто. Достаточно просто выбрать диск, который надо дефрагментировать, и нажать кнопку Next, а дальше остается лишь наблюдать. По завершении работы Disk Defrag дает краткий обзор результатов, показывая общее число файлов, каталогов, фрагментированных файлов, дефрагментированных файлов и пропущенных файлов, а также процент понижения фрагментации. При желании можно также нажать на кнопку Display Report в Disk Defrag для создания версии отчета о дефрагментации в формате HTML. Этот отчет дает некоторую дополнительную полезную информацию о диске, такую как список пропущенных файлов с их местонахождениями, число фрагментов, потраченное на дефрагментацию время и информацию о кластерах данного диска.

Цена: бесплатно.
Disk Defrag прост в установке и использовании
Disk Defrag прост в установке и использовании

Передача файлов
FileZilla
filezilla.sourceforge.net
Ничто так не упрощает работу, как хороший клиент SFTP, и это вдвойне верно, когда клиент основательно написан и бесплатен – как FileZilla. FileZilla – проект с открытым исходным кодом, размещенный на SourceForge.net, который был начат Тимом Коссе (Tim Kosse) и группой его последователей в 2001 г. как часть курсового задания по информатике. FileZilla работает на всех разновидностях Windows, от Windows NT®4.0 до Windows Vista. Проект заметно разросся за прошедшие шесть лет, но Коссе все еще руководит проектированием приложения.
В дополнение к стандартным подключениям по FTP, клиент поддерживает подключения по SFTP с помощью Secure Shell версии 2 (SSH2), FTP через TLS и FTP через SSL, с явным и неявным шифрованием, что позволяет подключаться к самым разнообразным серверам. FileZilla может приспосабливаться к локальным брандмауэрам через возможность пользователя ограничить круг используемых локальных портов или установить определенную привязку IP для не-пассивных передач как для IPv4, так и для IPv6. Клиент также поддерживает набор настроек прокси, включая прокси для SOCKS4/5, HTTP1.1 и FTP.
Что же касается проверки подлинности сервера для подключений по FTP, FileZilla поддерживает проверку подлинности по учетной записи, по имени пользователя/паролю и анонимную. Кроме того, пользователь может включить поддержку Kerberos Generic Security Services (GSS) (если Kerberos для Windows установлен на его компьютере) и создать список серверов с поддержкой GSS. Само собой, чтобы GSS начала работать для него, понадобится действительный билет Kerberos v5. Можно также включить поддержку своего сервера Ident для подключения к серверам, которые требуют ее как средство идентификации клиента.
FileZilla легко управляет большими собраниями узлов FTP и позволяет упорядочить свои подключения в древоподобную структуру. Кроме того, для каждого установленного подключения можно установить локальный и удаленный каталоги по умолчанию, указать порт, к которому следует подключаться, указать подключению обходить настроенный прокси, прямо выбрать активный или пассивный режим передачи и даже установить смещение часового пояса сервера. В дополнение к сохраненным подключениям FileZilla также располагает функцией Quickconnect для одноразовых передач, позволяя просто ввести адрес, имя пользователя, пароль и порт и затем нажать кнопку для подключения. После настройки всех параметров и подключений их можно экспортировать в XML для создания резервной копии или использования на других системах.
Пользовательский интерфейс приложения подобен интерфейсу проводника Windows и позволяет просто перетаскивать файлы между локальными и удаленными системами. Для передачи файлов можно указать параметры перезаписи файлов по умолчанию, в дополнение к возможности ограничения скоростей загрузки и отправки файлов на основе предварительно определенного набора правил или постоянного лимита скорости в кБ/с. По умолчанию, FileZilla настроена на использование сжатия файлов в режиме MODE Z при их передаче на серверы, поддерживающие такой режим, но пользователь может изменить уровень сжатия или отключить эту функцию. В клиенте также имеется функция очереди на передачу, которая позволяет поставить в очередь набор файлов, которые надо передать, а затем экспортировать и импортировать их список для повторного использования. Это очень полезно при выполнении часто повторяющихся задач системного администратора.

Цена: бесплатно.

Правка исполнимых файлов
PE Explorer
www.heaventools.com
Те, кто действительно хочет разобраться в деталях работы своих приложений, могут пожелать познакомиться с PE Explorer от компании HeavenTools. Это приложение позволяет вскрыть внутренние механизмы работы переносимых исполнимых файлов (PE), которые используются для исполнимых двоичных файлов в приложениях Windows. Попросту говоря, PE Explorer предоставляет интерфейс пользователя для исследования и правки содержимого этих исполнимых файлов. PE Explorer может открывать разнообразные типы файлов, начиная от обычных, вроде EXE и DLL, заканчивая менее известными, вроде DPL и CPL.
Когда пользователь впервые решает исследовать исполняемый файл, PE Explorer показывает ему сведения о заголовках файла, такую как число разделов кода, размер образа, подсистему приложения и информацию о размере стека. В другом представлении предоставлен обзор заголовков разделов в исполняемом файле – при двойном щелчке заголовка раздела выводится окно, дающее возможность исследовать содержимое каждого раздела.
Определенно предназначенное не для слабых духом, приложение позволяет извлекать, заново рассчитывать и удалять разделы загруженного PE. Средство просмотра цифровой подписи приложения, прекрасное средство обнаружения вирусов, вредоносных программ и прочих исполняемых пакостей, позволяет просмотреть и подтвердить цифровую подпись Microsoft Authenticode, если она присутствует в загруженном исполнимом файле. Это эффективный способ проверки издателя и целостности исполняемого файла.
PE Explorer также содержит встроенное средство быстрого дисассемблирования, позволяющее просмотреть ассемблерный код исполняемого файла. Он также поддерживает стандартные наборы инструкций Intel x86 вместе с такими расширениями, как MMX, 3D Now! и SSE/2/3. Средство дисассемблирования также извлекает строки текста ASCII из информационной части PE.
Еще одна функция программы – проверка зависимостей (Dependency Scanner), которая проверяет все модули, на которые файл PE ссылается статически, а также модули, загружаемые с задержкой, и затем отображает их в виде иерархического дерева, показывая, к чему обращается PE.
Одной из наиболее занятных частей PE Explorer, по моему мнению, является редактор ресурсов (Resource Editor). Эта функция позволяет просматривать, извлекать, заменять править и удалять ресурсы указанного исполняемого файла. Интерфейс пользователя показывает подобную каталогу структуру внедренных ресурсов, таких как изображения, звуковые файлы, диалоги, меню, данные XML, данные HTML и панели инструментов. Не все эти ресурсы поддерживают прямую правку, но большинство можно править и заменять. Это позволяет, например, добавить к приложению свою собственную эмблему, изменить сообщения в диалоге, поменять действия на панели инструментов и так далее без прямого доступа к исходному коду. PE Explorer является весьма удобным средством для того, кто желает покопаться в исполнимых файлах. Но если из всех его функций действительно нужен лишь редактор ресурсов, лучше обратить внимание на намного более дешевое приложение Resource Tuner от той же компании.

Цена: 129 долларов США, напрямую, за именную лицензию; 199 долларов США, напрямую, за корпоративную лицензию.
Оцените peexplorer

Обзор книги
«Безопасность конечных точек» («Endpoint Security»)
www.awprofessional.com
Добавление прочного, как скала, традиционного периметра сети к внутренней инфраструктуре является важным элементом защиты своих активов. Но это не панацея. Повышенная мобильность и возможности подключения к сети современного оборудования и программного обеспечения практически ликвидируют периметр корпоративной инфраструктуры – напротив, инфраструктура расширяется до этих удаленных конечных точек. На деле, покуда усиливается защита от атак извне среды, более вероятно, что атака будет случайно запущена пользователем, принесшим портативный компьютер из дома и заскочившим на неконтролируемую корпоративную сеть.
Тем, кто стремится идти в ногу со временем в области контроля за доступом к сети и обезопасить конечные точки своей инфраструктуры, стоит познакомиться с книгой Марка Кадрича (Mark Kadrich) «Безопасность конечных точек» («Endpoint Security»), выпущенной издательством Addison-Wesley Professional в 2007 г.. Книга начинается с четкого определения понятия конечной точки и затем дает представление о множестве существующих ее вариантов – клиенты Windows, клиенты Linux, внедренные устройства, мобильные телефоны и КПК. Кадрич рассматривает сеть как «задачу управления». Отказываясь от обычного представления сложной сети через аналогии с организмом, он, вместо этого, описывает ее как нечто, что можно четко разграничить и изобразить пригодным для практического использования образом.
Книга углубляется в основы управления сетевым доступом (NAC) и установки базового уровня доверия. Здесь же включены советы по составлению безопасных базовых требований для систем в конечных точках путем управления исходным программным обеспечением и средой сборки и укрепления их безопасности. Обзор средств, позволяющих укрепить безопасность и надежность конечных точек, охватывает хорошо знакомые средства вроде использования брандмауэров и антивирусного программного обеспечения, указывает на необходимость упреждающей работы с исправлениями и, наконец, на более продвинутые средства вроде систем обнаружения и предотвращения вторжений, проверщиков целостности узлов и шифрования.
Вторая половина книги посвящена подробностям обеспечения безопасности операционных систем различных типов клиентов, включая Microsoft Windows, Apple OS X и Linux. Каждая из этих глав дает обзор того, как провести первоначальную проверку состояния системы в конечной точке. Специальные главы посвящены КПК, смартфонам и встроенным устройствам; в них рассказано, как эти устройства сделались серьезной угрозой безопасности инфраструктур и как обезопасить различные типы связи на них.
Наконец, Кадрич рассматривает четыре конкретных примера и указывает, как конечные точки стали источником риска в каждом из них и как можно было бы уменьшить угрозу. В целом, книга «Endpoint Security» полна полезной информации для специалиста в области безопасности и предлагает не привязанный к конкретному поставщику взгляд на обеспечение безопасности сети с помощью преимуществ, предоставляемых периметром конечных точек.

Цена: 54,99 долларов США по каталогу.

Грэг Стин (Greg Steen) – специалист по информационным технологиям, предприниматель и энтузиаст поиска новых средств и ссылок, облегчающих работу и процесс разработки специалистам по информационным технологиям. Вы можете что-то ему предложить? Сообщите ему через tntools@microsoft.com


 Вопросы и ответы по SQL: Триггеры, срабатывающие при входе в систему, средства дефрагментации файлов данных и другое
Вопросы и ответы по SQL
Триггеры, срабатывающие при входе в систему, средства дефрагментации файлов данных и другое
Под редакцией Нэнси Мичелл (Nancy Michell)

Настройка служебной учетной записи
Совет: Используйте более защищенные пароли
SQL Server 2000 сохраняет две копии пароля. Одна — это исходный пользовательский пароль, другая — его версия, в которой все буквы находятся в верхнем регистре.
Такая практика облегчает проверку паролей, не зависящую от регистра. Доступ к серверу будет разрешен как для пароля, состоящего только из заглавных букв, так и для пароля, в котором встречаются прописные и строчные буквы. У такого удобства, однако, есть один недостаток... Хранение паролей в верхнем регистре облегчает подбор пароля полным перебором, поскольку снижает количество возможных комбинаций.
SQL Server 2005 хранит только оригинальный вариант пароля. Пароль, введенный пользователем, должен совпадать с паролем, хранящимся на сервере. Если они не совпадают, вход в систему заканчивается неудачей, и пользователь не получает доступа к серверу. Если вы забыли точный регистр всех букв, пароль необходимо сбросить.
Например, если имя пользователя SQLCOMMUNITY, пароль для SQL Server можно сбросить, выполнив следующую команду:
Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';
Для пользователя SQL Server с именем SQLCOMMUNITY эта команда сбросит старый пароль и установит новый пароль "k3t9h4s8wJF7t".

В.: В SQL Server™ 2000 служебная учетная запись для механизма и агента сервера SQL устанавливалась с помощью приложения «Службы» в пункте «Администрирование панели управления ОС». По слухам, в SQL Server 2005 будут использоваться средства диспетчера настройки. Почему нельзя по-прежнему использовать средства Windows?
О.: SQL Server 2005 разработан с целью повышения безопасности по сравнению с предыдущими версиями. Во многих случаях пользователи запускали бы SQL Server под одной из внутренних учетных записей, например LocalSystem. Но, как правило, у этих учетных записей Windows® или слишком мало, или слишком много прав. Для работы механизма и агента SQL Server 2005 не нужно создавать учетную запись с повышенными привилегиями Windows. Диспетчер настройки позволяет выбрать такие учетные записи, для которых нужный набор прав SQL Server и операционной системы уже установлен автоматически. Управляя же службами SQL Server с помощью средств Windows, можно не предоставить нужные или предоставить лишние права доступа.
Дополнительные сведения приведены в совете «поменять служебную учетную запись».

Кто регистрируется на моем сервере?
В: Я хочу знать, кто и когда регистрировался на моем сервере. Кроме того, я хочу разрешить доступ некоторым пользователям только в определенные периоды времени. Мне бы также хотелось знать, как отслеживать действия пользователей. Хоть что-нибудь из этого возможно?
О: Да, все перечисленные задачи можно решить, используя SQL Server 2005 с установленным пакетом обновления 2.
SQL Server 2005 может создавать триггеры входа в систему, которые в ответ на событие LOGON запускают процедуру T-SQL или вызывают сохраненную процедуру. Триггеры входа в систему можно использовать для аудита и управления пользователями, отслеживая с их помощью количество входов в систему, ограничивая возможности входа в SQL Server или ограничивая количество сеансов для определенных пользовательских имен. Это событие порождается после успешной проверки подлинности имени входа пользователя в систему, но до установления его сеанса. Следовательно, все сообщения, которые выводит триггер оператором PRINT (информационные сообщения и сообщения об ошибках), отправляются в журнал ошибок SQL Server. Если проверка подлинности пользователя при входе заканчивается неудачей, то триггеры входа в систему не запускаются.
В следующем примере показано, как можно создать триггер входа в систему и посылать из него сообщения в журнал ошибок SQL Server:
ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO
Следующий запрос выводит все триггеры, установленные на серверном уровне:
SELECT * FROM sys.server_triggers;

Дефрагментация файлов: практические рекомендации
Как лучше всего избавиться от фрагментации файлов данных SQL Server? Средства дефрагментации Windows рассматривают файл данных SQL как единое целое и не дефрагментируют его.
О: Можно создать резервную копию базы данных, а потом восстановить из нее базу. Если на диске достаточно места, чтобы записать непрерывный файл данных, то база данных после восстановления будет непрерывной. С другой стороны, не стоит останавливать базу только для дефрагментации ее физических файлов данных. Обычно на уровне операционной системы фрагментация все равно невелика, а чтобы уменьшить внутреннюю фрагментацию, вполне достаточно регулярно переиндексировать базу. Это повысит до максимума эффективность упреждающего чтения и количество буферизуемых данных.
Эффективность дискового ввода-вывода в основном определяют следующие факторы: правильный подбор дисков и настройка RAID; своевременное масштабирование дискового массива в случае увеличения объема ввода-вывода; поддержание соответствующей компоновки файлов журналов, данных, временных данных и резервных копий. Отказавшись от автоматического увеличения и сжатия файлов данных, тоже можно уменьшить фрагментацию файла на уровне тома. Например, если размер файла данных автоматически увеличивается 10 раз на 500 МБ, то к файлу на диске может добавиться до 10 новых фрагментов. Если же один раз вручную увеличить размер файла на 5 ГБ, добавится только 1 фрагмент.

Знаете ли вы, что когда для SQL Server настраивается служебная учетная запись Windows NT®, SQL Server устанавливает нужные ему права доступа на некоторые файлы, папки и разделы реестра Windows? Из консоли «Службы» пункта Администрирование тоже можно создать служебную учетную запись для SQL Server. Однако в этом случае нужные права и полномочия не будут установлены, что может привести к серьезным проблемам из-за отсутствия нужных параметров безопасности в упомянутых выше элементах SQL Server и Windows.
Учитывая вышесказанное, настоятельно рекомендуется использовать диспетчер настройки SQL Server вместо консоли «Службы» для изменения служебной учетной записи SQL Server или агента SQL Server. Однако даже если учетная запись изменялась из консоли «Службы», последствия этого можно устранить.
Шаг 1: Разрешите все права доступа к следующим разделам и подразделам реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>
Шаг 2: Установите полный доступ стартовой учетной записи служб MSSQLServer и SQLServerAgent (локальной или доменной учетной записи Windows NT) на следующую папку NTFS:
Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL
Однако вместо того, чтобы делать это вручную, рекомендуется менять служебные записи SQL Server и его агента с помощью диспетчера настройки SQL Server.

Благодарим за технические консультации следующих специалистов по информационным технологиям корпорации Майкрософт: Кэри Готтсман, Салим Хакани, Трейс Джордан, Питер Кальбах, Эл Ноэл, Уттам Паруи, Эмбер Ситко и Бак Вуди.


 Обзор служебных программ: Virtual Machine Remote Control Plus
Обзор служебных программ
Virtual Machine Remote Control Plus
Маттийс тен Селдам (Matthijs ten Seldam)
Загрузить исходный код для этой статьи: UtilitySpotlight2007_10.exe (10163KB)

В последнее время виртуализация является злободневной темой. Многие специалисты в области ИТ используют виртуализацию оборудования для изучения и тестирования ситуаций. Учитывая это, Майкрософт предлагает Virtual PC 2007 — программное решение для виртуализации, предназначенное для автономных установок с ограниченным числом виртуальных машин. Отметим, что этот новый программный продукт не заменяет Virtual Server
2005, который привнес виртуализацию в центр данных.
Microsoft® Virtual Server 2005 позволяет провести виртуализацию большого числа рабочих нагрузок сервера, но, в отличие от Virtual PC, интерфейс виртуального сервера является веб-приложением. Хотя управление на основе веб-технологий имеет свои преимущества, для повседневного администрирования многие предпочитают пользовательский интерфейс с широкими возможностями, который ведет себя, как приложение Windows®.
Virtual Machine Remote Control Plus (кратко — VMRCplus) является альтернативным пользовательским интерфейсом для Virtual Server 2005. Будучи приложением Windows Forms, VMRCplus предлагает удобные средства управления виртуальным сервером и его виртуальными машинами. Отметим, что виртуальный сервер поставляется со средством под названием VMRC, которое используется для удаленного управления виртуальными машинами. Но VMRCplus предлагает в одном приложении и управление настройкой виртуального сервера, и удаленное управление виртуальными машинами.

Диспетчер виртуальной машины
Главное окно VMRCplus, которое называется «Диспетчер виртуальных машин», показано на рис. 1. В этом примере диспетчер виртуальных машин подключен к локальному узлу с пятью работающими машинами, тремя в сохраненном состоянии, а все остальные отключены. В списке выбрана шестая машина, и отображается дополнительная информация, включая гостевую операционную систему, статистику загрузки ЦП, дисковых и сетевых операций ввода и вывода, а также версию установленных дополнений. Обратите внимание, что список упорядочен по параметру Status.
Рис. 1 Диспетчер виртуальной машины VMRCplus
Рис. 1 Диспетчер виртуальной машины VMRCplus
Посредством диспетчера виртуальной машины можно подключаться к узлам виртуального сервера и отображать их виртуальные машины. Переключение между узлами выполняется выбором вкладки узла, а подключение к узлу осуществляется из раскрывающегося списка инструментальной панели или с помощью ввода имени узла или адреса IP. После успешного подключения VMRCplus добавляет в список имя или IP-адрес.
Внизу окна отображаются некоторые свойства узла виртуального сервера, такие как информация о ЦП и памяти. Счетчик памяти предоставляет краткий обзор объема ОЗУ, доступного для виртуальных машин.

Управление виртуальным сервером
Диспетчер виртуальных машин не просто отображает информацию — предусмотрена также настройка параметров. В пункте меню «Вид» можно установить интервал обновления, используемый VMRCplus для обновления списка виртуальных машин. Текущее значение интервала обновления отображается в правом нижнем углу окна, как показано на рис. 1.
В меню «Виртуальный сервер» предоставляется доступ к настройке виртуального сервера, включая параметры удаленного управления машиной (VMRC), местоположение по умолчанию для новых виртуальных машин, параметры безопасности и свойства службы. На странице параметров VMRC можно указать значения любых свойств, одновременно отключить VMRC или возвратиться к значениям по умолчанию для параметров виртуального сервера.
На странице параметров безопасности можно указать разрешения виртуального сервера. По умолчанию локальная группа «Администраторы» обладает полным контролем над виртуальным сервером. Можно указывать разрешения для групп или пользователей. Если вы не являетесь членом локальной группы администраторов, сначала следует добавить группу или вашу учетную запись и установить соответствующие разрешения. В действительности нет необходимости работать с VMRCplus в качестве администратора; вполне достаточно обычных разрешений пользователя.
Свойства узла виртуального сервера, включая физические свойства, показаны на рис. 2. Обратите внимание, что этот узел поддерживает виртуализацию, поддержанную оборудованием, что видно из характеристик процессора.
Рис. 2 Свойства виртуального сервера
Рис. 2 Свойства виртуального сервера

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

Управление виртуальной машиной
Все предыдущие диспетчеры предназначались для управления виртуальным сервером. Что VMRCplus предлагает для создания и настройки виртуальных машин?
Создание виртуальных машин выполняется крайне просто: достаточно выбрать в меню «Виртуальная машина | Создание». В открывшемся диалоговом окне предлагается несколько вариантов по умолчанию, эквивалентных вариантам виртуального сервера, но за интерфейсом скрываются отличия. Например, VMRCplus всегда создает два виртуальных жестких диска и присоединяет их к SCSI. Кроме этого, VMRCplus позволяет создавать несколько виртуальных машин за один прием. Достаточно выбрать пункт «Создание нескольких виртуальных машин» и указать требуемое число. К указанному имени машины VMRCplus добавляет дефис и порядковый номер.
Поистине замечательной функцией является возможность создания из родительской виртуальной машины нескольких виртуальных машин. Предположим, что создана виртуальная машина с самыми новыми добавлениями, пакетом обновления, исправлениями и инструментами, и на ее основе требуется создать другие виртуальные машины. Если на завершающем этапе запустить sysprep и отключить родительскую машину, затем можно создать несколько виртуальных машин, наследующих свойства родительской.
В течение секунд можно создать множество виртуальных машин на основе этой родительской, и новые виртуальные машины быстро запускаются с помощью одной и той же ссылки. По завершении — например, тестирования, — просто удалите их. Это выполняется так же просто: VMRCplus поддерживает множественный выбор в списке виртуальных машин, а также упорядочение столбцов. Поэтому нетрудно выбрать и изъять несколько виртуальных машин (при этом они просто убираются из списка), виртуальные машины можно также удалить (при этом удаляются также и файлы).
Существуют другие команды множественного выбора, которые можно использовать на виртуальных машинах, например множественный выбор и запуск, множественный выбор и открытие консоли или множественный выбор и сохранение состояния. Все эти команды можно выполнять либо через пользовательский интерфейс, либо с помощью клавиш быстрого доступа.
Настройка виртуальной машины легко выполняется и с помощью страницы параметров оборудования. Можно установить объем памяти, добавить контроллеры SCSI, подключить диски или образы (да-да, с помощью перетаскивания мышью) и активировать и настроить сетевые адаптеры. В окне дополнительных свойств предусмотрена возможность установки более сложных элементов настройки. Например, можно, запустив виртуальную машину с использованием специальной учетной записи пользователя, настроить автоматический запуск машины при запуске виртуального сервера.

Удаленное управление
Наконец, в VMRCplus имеется диспетчер консоли, в который входят сеансы удаленного управления (сеансы VMRC) виртуальными машинами. Консоль открывается посредством выбора запущенной виртуальной машины (или нескольких) и нажатия кнопки консоли виртуальной машины на панели свойств.
Окно «Диспетчер консоли», показанное на рис. 3, поддерживает удаленные сеансы, упорядоченные с помощью вкладок. Переключение между виртуальными машинами осуществляется выбором соответствующей вкладки. Имеется также панель инструментов, содержащая наиболее часто используемые функции.
Рис. 3 Диспетчер консоли
Рис. 3 Диспетчер консоли
Как видно из рисунка, диспетчер консоли снабжен контекстными меню, позволяющими присоединять изображение виртуальной дискеты или образ ISO, подключать диски узла и устанавливать текущие добавления. Имеется также строка состояния, в которой отображается состояние компакт-диска/диска DVD и дискеты, версия текущих добавлений на виртуальной машине, активный в текущий момент ключ узла и параметр динамического изменения размера экрана. VMRCplus дает возможность задавать ключ узла. Предусмотрен также доступ к параметрам оборудования виртуальной машины и дополнительным свойствам.
VMRCplus предлагает и некоторые другие удобные функции. Например, можно получить копию экрана с параметрами виртуальной машины и сохранить ее в виде файла .jpg, который может пригодиться при поиске и устранении неполадок. Можно также «Передать текст на виртуальную машину», что означает передачу текста на виртуальную машину посредством нажатий клавиш. Эта функция работает не так, как буфер обмена, но она очень удобна в тех ситуациях, когда, например, требуется скопировать ключ программного продукта с узла и вставить на виртуальной машине.
Изначально VMRCplus разрабатывалась Полем Деспом (Paul Despe) в качестве средства разработчика, выполняющего некоторые основные функции, но не охватывавшего все функции виртуального сервера. Она использовалась только для целей тестирования и содержала некоторые проблемы. Примерно год назад я взял код и начал его переписывать, улучшать и расширять функциональные возможности. С тех пор эта служебная программа стала невероятно популярной в Майкрософт среди пользователей виртуального сервера. Отмечу, однако, что VMRCplus не является приложением, поддерживаемым Майкрософт. Она предоставляется «как есть» и на нее распространяется лицензионное соглашение для конечного пользователя.
VMRCplus разрабатывалась для Virtual Server 2005 с пакетом обновления 1 (SP1). Хотя предыдущие версии должны быть с ней совместимы, она проходила тестирование только с пакетом обновления 1 (SP1). Вследствие этого, прежде чем ею пользоваться, пользователям необходимо обновить свои узлы виртуального сервера до уровня пакета обновления 1 (SP1). VMRCplus можно загрузить с веб-узла журнала TechNet Magazine по адресу technetmagazine.com/code07.aspx.

Маттийс тен Селдам (Matthijs ten Seldam) работает в качестве главного консультанта в консультационной службе Майкрософт. Он специализируется в области безопасности, развертывания и автоматизации и является также специалистом в области виртуализации.


 Бизнес информационных технологий: Расчет ценности информационно-технической инфраструктуры в правительстве
Бизнес информационных технологий
Расчет ценности информационно-технической инфраструктуры в правительстве
Асер Маамун (Acer Maamoun)

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

Оправдание вложений
Обычной жалобой в организациях и отделах ИТ является перегруженность запросами из множества различных областей бизнеса, каждый из которых является срочным. Новые инициативы обычно соответствуют нормативным требованиям или приоритетам долговременных целей конкретного отдела. Эти инициативы могут показаться случайным набором, но на деле они часто близко соответствуют работе для общества, которую стремится выполнять данный отдел.
С другой стороны, эксплуатационные затраты, распределяемые в соответствии с тем, сколько денег используется для поддержки отдельных операций отдела, могут скрыть стоимость (и ценность) функций, охватывающих все предприятие, или совместно используемых служб. В такой среде ценность вложений в новую инфраструктуру или улучшение существующей, влияющей все предприятие или непрямо соответствующей задачам конкретных отделов, иногда чрезвычайно сложно правильно оценить.
Как следствие, организация ИТ в целом часто затрудняется в поддержании корпоративного взгляда на информационные технологии, как он описан в документе Управления служб общего назначения (GSA) «Концепция архитектуры федеральных предприятий» (whitehouse.gov/omb/egov/a-1-fea.html). В такой среде трудноосуществима большая часть усилий по внедрению общего взгляда на архитектуру предприятия, единой модели создания экономических обоснований и процесса управления портфелями проектов с целью уравнивания шансов запросов на вложения в информационные технологии с другими запросами. Более эффективной моделью является поддержка портфеля работ по ИТ, чья ценность для общества дает наибольшую отдачу. Это требует выбора и строгого соблюдения общих критериев общественной ценности в процессе создания экономических обоснований, управления портфелями, реализации выгод и оценки.

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

Выбор методологии планирования
На рис. 1 приведена сводка «за» и «против» каждого метода, а также подходящие для его применения обстоятельства. После того, как метод выбран, он должен последовательно использоваться всей организацией для обеспечения сравнимости.
Figure 1 Методики экономических обоснований (Close Figure 1)

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

Асер Маамун (Acer Maamoun) - консультант в области корпоративной стратегии, работающий на корпорацию Майкрософт. Он обладает более чем 18 годами опыта в областях стратегии развития информационных технологий и бизнес-ориентации.


 Кабельщик: Протокол IP с проверкой подлинности
Кабельщик
Протокол IP с проверкой подлинности
Джозеф Дэвис (Joseph Davies)
В некоторых частях этой статьи обсуждается предварительная версия Windows Server 2008. Эти детали в дальнейшем могут измениться.

Операционные системы Windows Vista и Windows Server 2008 (сейчас проходит этап бета-тестирования) поддерживают протокол IP с проверкой подлинности (AuthIP), улучшенную версию протокола IKE. Протоколы AuthIP и IKE используются для определения материала ключа и согласования параметров безопасности для связи, защищенной с помощью
протокола IPsec. AuthIP обеспечивает упрощенную поддержку и настройку политики IPsec во множестве конфигураций и предоставляет дополнительную гибкость для проверки подлинности узлов IPsec. В данной статье описывается протокол AuthIP и совместная работа узлов IPsec, поддерживающих AuthIP и IKE или только IKE.

Обзор протокола IKE
Примеры согласования
Для демонстрации совместной работы давайте посмотрим, что происходит между узлами IPsec под управлением Windows Vista и Windows XP при попытке согласования защиты IPsec.

Пример 1: два узла IPsec под управлением Windows Vista в режиме запроса
В этом примере узел IPsec под управлением Windows Vista (Узел 1) является инициатором, а респондент также работает под управлением Windows Vista (Узел 2). Для обоих узлов установлен режим запроса для входящей и исходящей связи. В режиме запроса узел IPsec запрашивает защиту IPsec, но не требует ее. Узлы обмениваются следующими сообщениями.
  1. Узел 1 отправляет сегмент TCP synchronize (SYN) открытым текстом, инициализируя подключение по TCP с Узлом 2.
  2. Узел 2 отправляет сегмент TCP SYN-Acknowledgment (ACK).
  3. Узел 1 отправляет сегмент ACK TCP.
  4. Узел 1 отправляет сообщение ISAKMP на основе AuthIP, инициируя согласование основного режима AuthIP.
  5. Узел 1 отправляет сообщение ISAKMP на основе IKE, инициируя согласование основного режима IKE.
  6. Узел 2 отвечает сообщением ISAKMP на основе AuthIP, продолжая согласование основного режима AuthIP.
  7. Узлы 1 и 2 завершают согласование основного, быстрого и расширенного (дополнительно) режимов AuthIP.
  8. Последующие отправляемые через подключение по TCP сегменты защищены по протоколу IPsec.
Точный порядок сообщений 1 – 5 зависит от задержки сети. В этой статье описываются примеры для сети с очень маленькой задержкой, в которой подтверждение TCP (сообщения 1 – 3) завершается до отправки Узлом 1 первоначальных сообщений ISAKMP (сообщения 4 и 5). В сети с высокой задержкой узел 1 отправляет сегмент TCP SYN открытым текстом, сообщение ISAKMP на основе AuthIP, а затем сообщение ISAKMP на основе IKE как первые три сообщения процесса обмена сообщениями.

Пример 2: узел IPsec под управлением Windows Vista в режиме запроса и узел IPsec под управлением Windows XP в режиме запроса
В этом примере узел IPsec под управлением Windows Vista (Узел 1) является инициатором, а респондент работает под управлением Windows XP (Узел 2). Для обоих узлов установлен режим запроса для входящей и исходящей связи. Узлы обмениваются следующими сообщениями.
  1. Узел 1 отправляет сегмент SYN TCP открытым текстом, инициализируя подключение по TCP с Узлом 2.
  2. Узел 2 отправляет сегмент SYN-ACK TCP.
  3. Узел 1 отправляет сегмент ACK TCP.
  4. Узел 1 отправляет сообщение ISAKMP на основе AuthIP, инициируя согласование основного режима AuthIP.
  5. Узел 1 отправляет сообщение ISAKMP на основе IKE, инициируя согласование основного режима IKE.
  6. Узел 2 отвечает сообщением ISAKMP на основе IKE, продолжая согласование основного режима IKE.
  7. Узлы 1 и 2 завершают согласование основного и быстрого режимов IKE.
  8. Последующие отправляемые через подключение TCP сегменты защищены по протоколу IPsec.

Пример 3: узел IPsec под управлением Windows Vista в режиме запроса и узел IPsec под управлением Windows XP в режиме требования
В этом примере узел IPsec под управлением Windows Vista (Узел 1) является инициатором, а респондент работает под управлением Windows XP (Узел 2). Для Узла 1 установлен режим запроса для исходящей связи, а для Узла 2 установлен режим требования для входящей связи. В режиме требования узел IPsec запрашивает защиту IPsec и отвергает незащищенные пакеты без уведомления. Узлы обмениваются следующими сообщениями.
  1. Узел 1 отправляет сегмент SYN TCP в открытом тексте, инициируя подключение по TCP, которое Узел 2 отвергает без уведомления.
  2. Узел 1 отправляет сообщение ISAKMP на основе AuthIP, инициируя согласование основного режима AuthIP, которое Узел 2 отвергает без уведомления.
  3. Узел 1 отправляет сообщение ISAKMP на основе IKE, инициируя согласование основного режима IKE.
  4. Узел 2 отвечает сообщением ISAKMP на основе IKE, продолжая согласование основного режима IKE.
  5. Узлы 1 и 2 завершают согласование основного и быстрого режимов IKE.
  6. Узел 1 пересылает сегмент TCP SYN (защищенный по протоколу IPsec).
  7. Узел 2 отправляет сегмент TCP SYN-ACK (защищенный по протоколу IPsec).
  8. Узел 1 отправляет сегмент TCP ACK (защищенный по протоколу IPsec).

IKE – это стандарт Интернета, определенный в RFC 2409 (ietf.org/rfc/rfc2409.txt) и определяющий механизм установления сопоставлений безопасности IPsec. Сопоставления безопасности – это взаимно согласовываемые политики и ключи, определяющие механизмы и службы обеспечения безопасности для защиты связи между узлами IPsec. В частности, IKE объединяет протокол ISAKMP (Internet Security Association and Key Management Protocol) в RFC 2408 и протокол Oakley Key Determination Protocol (RFC 2412). IKE использует протокол Oakley Key Determination для создания данных секретных ключей для защищенной связи.
IKE использует протокол ISAKMP для согласования сопоставлений безопасности. ISAKMP включает средства для определения и проверки подлинности узлов, управления сопоставлениями безопасности и обмена данными ключей. ISAKMP – это платформа для согласования защищенной связи, независимая от определенных протоколов обмена ключами, алгоритмов шифрования и целостности и методов проверки подлинности.
Узлы IPsec используют IKE для выполнения согласования основного и быстрого режимов. При согласовании основного режима создается сопоставление безопасности ISAKMP, защищающее согласования безопасности. Во время согласования основного режима инициатор и респондент обмениваются сериями сообщений ISAKMP для согласования алгоритмов шифрования и хеширования для сопоставления безопасности ISAKMP, обмена данными определения ключей и взаимной идентификации и проверки подлинности.
В фазе согласования быстрого режима создаются два сопоставления безопасности IPsec (одно для входящих данных, а второе для исходящих данных), защищающие данные, передаваемые между двумя узлами IPsec. Во время согласования быстрого режима инициатор и респондент обмениваются сериями зашифрованных сообщений ISAKMP для согласования алгоритмов шифрования и хеширования для входящих и исходящих сопоставлений безопасности IPsec.
Дополнительные сведения о согласовании основного и быстрого режимов на основе IKE приведены в статье «IKE Negotiation for IPsec Security Associations» (Согласование IKE для сопоставлений безопасности IPsec) по адресу microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Обзор AuthIP
AuthIP – это улучшенная версия IKE, предоставляющая дополнительную гибкость с поддержкой проверки подлинности на основе пользователей, проверки подлинности с множеством учетных данных, улучшенного согласования метода проверки подлинности и асимметричной проверки подлинности. Как и IKE, AuthIP поддерживает согласование основного и быстрого режимов. AuthIP также поддерживает расширенный режим, часть согласования узла IPsec, во время которого может быть выполнен второй цикл проверки подлинности. Дополнительный расширенный режим может использоваться для многократной проверки подлинности. Например, в расширенном режиме можно выполнить отдельную проверку подлинности на основе компьютера и отдельную проверку подлинности на основе пользователя.
Поддержка многократной проверки подлинности является частью использования IPsec для платформы защиты доступа к сети (NAP), в которой узлы IPsec выполняют проверку подлинности с учетными данными компьютера и также используют сертификат работоспособности для подтверждения соответствия требованиями исправности системы. Дополнительные сведения о защите доступа к сети приведены на веб-узле microsoft.com/nap. Дополнительные сведения о функциях AuthIP приведены в статье «AuthIP in Windows Vista» (AuthIP в Windows Vista) по адресу microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Сообщения AuthIP
IKE и AuthIP используют протокол ISAKMP в качестве протокола обмена ключами и согласования сопоставления безопасности. Сообщения ISAKMP отправляются по протоколу UDP (User Datagram Protocol) и состоят из заголовка ISAKMP и одного или нескольких воспроизводимых фрагментов ISAKMP. Заголовок ISAKMP содержит сведения о сообщении, включая его тип. На рис. 1 показан формат заголовка ISAKMP.
Рис. 1 Формат заголовка ISAKMP
Рис. 1 Формат заголовка ISAKMP
В заголовке ISAKMP для полей «Файлы «Cookie» инициатора» и «Файлы «Cookie» респондента» устанавливаются случайные числа, не равные нулю, выбранные узлами IPsec. В поле «Следующие полезные данные» указывается первые полезные данные сообщения ISAKMP, находящиеся сразу за заголовком ISAKMP. В списке RFC 2408 определяются значения поля «Следующие полезные данные». Типы полезных данных 128-255 зарезервированы для частного использования. В полях «Основная версия» и «Дополнительная версия» указываются версии ISAKMP на узле IPsec, отправляющем сообщение ISAKMP. Для IKE и AuthIP основная версия – 1, а дополнительная версия – 0.
В поле «Тип обмена» указывается тип выполняемого обмена ISAKMP. Тип обмена определяет структуру и порядок полезных данных ISAKMP. RFC 2408 определяет значения поля «Тип обмена». Типы обмена128-255 зарезервированы для частного использования.
В поле «Флаги» содержатся три флага, определенные в RFC 2408. Младший бит (бит 0) – это бит Encryption, обозначающий шифрование полезных данных ISAKMP (если установлено значение 1) или отсутствие шифрования (если установлено значение 0). Шифрование осуществляется с помощью алгоритма, согласованного для сопоставления безопасности ISAKMP, который определяется сочетанием полей «Файлы «cookie» инициатора» и «Файлы «cookie» респондента». Следующий младший бит (бит 1) – это бит Commit, обозначающий синхронизацию обмена ключами (если установлено значение 1) или отсутствие такой синхронизации (если установлено значение 0). Бит Commit используется для удостоверения выполнения согласования сопоставления безопасности до отправки зашифрованных данных. Следующий младший бит (бит 2) – это бит Authentication Only, используемый для обозначения того, что в сообщении содержатся (если установлено значение 1) или не содержатся (если установлено значение 0) все полезные данные извещения типа информационного обмена и выполнена проверка подлинности, но отсутствует шифрование.
В поле «Код сообщения» содержится уникальный идентификатор сообщения. Поле «Код сообщения» используется для предотвращения коллизий, когда оба узла IPsec одновременно пытаются установить сопоставление безопасности IPsec. В поле «Длина» указывается длина всего сообщения ISAKMP.
В случае IKE сообщение ISAKMP содержит ряд полезных данных ISAKMP. Первыми полезными данными, указанными в поле «Следующие полезные данные», является заголовок ISAKMP. Все полезные данные ISAKMP имеют собственные поля «Следующие полезные данные» для обозначения следующих полезных данных. Для поля «Следующие полезные данные» в последних полезных данных установлено значение 0. На рис. 2 показан формат сообщений IKE.
Рис. 2 Формат сообщений IKE
Рис. 2 Формат сообщений IKE
AuthIP использует сообщения ISAKMP, для которых в поле «Тип обмена» заголовка ISAKMP установлены типы обмена 243 (основной режим), 244 (быстрый режим), 245 (расширенный режим) и 246 (уведомление). Важным отличием сообщений ISAKMP на основе AuthIP является то, что они содержат только один тип полезных данных ISAKMP: полезные данные уведомления или шифрования. Полезные данные шифрования содержат внедренные полезные данные, используемые для согласования основного, быстрого и расширенного режимов. Полезные данные шифрования могут содержать набор зашифрованных полезных данных или полезных данных в открытом тексте в зависимости от бита Encryption поля «Флаги» заголовка ISAKMP. На рис. 3 показан формат сообщений AuthIP с полезными данными шифрования.
Рис. 3 Формат сообщений AuthIP с полезными данными шифрования
Рис. 3 Формат сообщений AuthIP с полезными данными шифрования

Совместное использование AuthIP и IKE
Операционные системы Windows Vista® и Windows Server® 2008 поддерживают как IKE, так и AuthIP. Однако операционные системы Windows® XP и Windows Server 2003 поддерживают только IKE. Инициализирующий узел IPsec, поддерживающий AuthIP и IKE и имеющий политику безопасности соединения, использующую AuthIP и IKE, должен определить поддержку AuthIP или IKE отвечающим узлом IPsec. Затем он должен использовать наиболее подходящий протокол для согласования защиты IPsec, отдавая предпочтение использованию AuthIP, а не IKE.
Для определения протокола согласования отвечающего узла IPsec инициализирующий узел IPsec, использующий AuthIP и IKE, одновременно отправляет следующие сообщения.
  • Сообщение 1 — сообщение AuthIP, инициирующее согласование основного режима
  • Сообщение 2 — сообщение IKE, инициирующее согласование основного режима
Если отвечающий узел поддерживает AuthIP, на сообщение 1 он должен ответить сообщением AuthIP, продолжая согласование основного режима, и отвергнуть сообщение 2 без уведомления. Отвечающий узел, не поддерживающий AuthIP, отвергает сообщение 1 без уведомления, поскольку в поле «Тип обмена» содержится неподдерживаемое значение, и отвечает на сообщение 2.
Для предотвращения согласования на основе IKE между узлами IPsec под управлением Windows Vista или Windows Server 2008, когда сообщение 1 отвергается из сети или приходит после сообщения 2, узлы IPsec под управлением Windows Vista или Windows Server 2008 отправляют сообщение 2 с полезными данными ISAKMP идентификатора поддерживаемого поставщика AuthIP. Полезные данные идентификатора поддерживаемого поставщика AuthIP указывают на то, что узел IPsec поддерживает AuthIP.
Поэтому, когда узел IPsec под управлением Windows Vista или Windows Server 2008 получает сообщение с 2 с полезными данными идентификатора поддерживаемого поставщика AuthIP, он ждет, когда инициализирующий узел IPsec повторно отправит сообщения 1 и 2, затем отвечает на сообщение 1.
Инициализирующий узел IPsec повторно отправляет сообщения 1 и 2 до получения ответа или истечения времени ожидания. После получения инициатором ответа он определяет возможности респондента с помощью заголовка ISAKMP ответа. Если для поля «Тип обмена» установлено значение 243 (тип обмена для согласования основного режима на основе AuthIP), респондент поддерживает AuthIP. Если для поля «Тип обмена» установлено значение 2 (тип обмена для согласования основного режима на основе IKE и защиты удостоверения), респондент поддерживает IKE.
В зависимости от ответа инициатор отвечает следующим сообщением AuthIP для согласования основного режима AuthIP или следующим сообщением IKE для согласования основного режима IKE. В течение срока действия сопоставления безопасности ISAKMP узел IPsec должен использовать протокол, использовавшийся для согласования сопоставления.

Джозеф Дэвис (Joseph Davies) работает составителем технической документации в корпорации Майкрософт и ведет ежемесячную рубрику TechNet «Кабельщик» по адресу Microsoft.com/technet/community/columns/cableguy.


 Windows PowerShell: Работаем без сценария
Windows PowerShell
Работаем без сценария
Дон Джонс (Don Jones)

Когда бы я ни рассказывал окружающим о Windows PowerShell — будь это на конференции, в общедоступной группе новостей Windows PowerShell или даже на моем веб-узле, каждый раз мне попадаются администраторы, сообщающие, что они «не торопятся» изучать Windows PowerShell. Почему? Чаще всего в качестве причины они сообщают о том,
что именно сейчас у них нет времени учиться написанию сценариев.
Это широко распространенное ощущение. Мы, администраторы, всегда очень заняты, и у нас действительно не хватает времени на изучение новых технологий. Но нам необходимо двигаться вперед, изучать новое программное обеспечение, например Windows Vista®, Windows Server® 2008 и Exchange Server 2007, и только так мы можем оставаться на верхнем уровне технологий, крайне важных для их работы. А Windows PowerShell™ представляет собой существенную часть этих технологий.
Еще одна причина, по которой откладывается изучение написания сценариев в Windows PowerShell (ее часто приводят администраторы), она заключается в том, что они, как сказал один администратор, «боятся стать программистами». Что же, в этом вопросе я могу вам помочь. Возможно, вы удивитесь, узнав, что с помощью Windows PowerShell можно делать поистине удивительные вещи, не написав ни строчки кода.

Подготовка для передачи по конвейеру
Я писал ранее о крайне гибком и мощном объектно-ориентированном конвейере, используемом в Windows PowerShell. (Даже если слова «объектно-ориентированный» вызывают у вас подозрения о том, что я направляюсь в сторону программирования, не убегайте.) Одним из моих любимых качеств конвейера является возможность использовать его в интерактивном режиме. Конвейер мгновенно выдает вам результаты и дает возможность уточнять их, позволяя вам получить в точности то, что требуется. Например, предположим, что для нескольких удаленных компьютеров требуется получить описание свободного пространства на диске. Далее, пусть имена этих компьютеров перечислены в текстовом файле с именем C:\Computers.txt. Это просто обычный текстовый файл, содержащий по одному имени компьютера в строке, — никаких сложностей, подобных базам данных.
Для начала я проверю, можно ли извлечь эту информацию из локального компьютера. В конце концов, если я справлюсь с этим на одном компьютере, выполнение такой же задачи на нескольких компьютерах не должно вызвать трудностей. Напомню, что в этой процедуре не должен участвовать сценарий! Я намерен выполнять все операции в оболочке в интерактивном режиме, получая результаты сразу после нажатия клавиши ВВОД.
В задачах такого рода есть одна хитрость. Возможно, каждый раз, когда требуется получить список с управляющей информации с удаленных компьютеров, вы пользуетесь WMI (инструментарием управления Windows®). Теперь предположим, для целей данного примера, что я знаю только то, что мне требуется использовать WMI. Поэтому я обращаюсь к функции поиска Live Search и в качестве выражения поиска ввожу «windows wmi free disk space». Появляется несколько результатов, среди которых есть фраза «Win32_LogicalDisk». Это мне кажется похожим на класс WMI, и, возможно, это то, что я ищу. Я даже не даю себе труда щелкнуть какой-либо из этих результатов поиска. Вместо этого я ввожу «Win32_LogicalDisk» в качестве нового выражения поиска, и первый из результатов ссылается на страницу с документацией по Win32_LogicalDisk, находящуюся на веб-узле MSDN® по адресу (msdn2.microsoft.com/aa394173.aspx). Поэтому я перехожу к этой странице и вижу, что одно из свойств этого класса называется FreeSpace, что звучит многообещающе.

Поиск командлета
Для следующего этапа мне требуется найти командлет, который извлечет для меня свойства класса WMI. Одним из примечательных качеств оболочки Windows PowerShell являются ее фантастические встроенные функции самораскрытия — оболочка облегчает получение информации о своих возможностях. Поэтому для выяснения того, что оболочке известно о работе с WMI, я ввожу «Help *wmi*». В результатах, показанных на рис. 1, содержится псевдоним Gwmi и командлет, на который он указывает — Get-WMIObject. По существу, для доступа к одному и тому же набору функций имеется два способа, т.е. нет необходимости в принятии твердого решения об использовании одного из них. Поскольку они делают одно и то же, и Gwmi набирается быстрее, я использую следующий вариант
Рис. 1 Что оболочке известно о работе с WMI
Рис. 1 Что оболочке известно о работе с WMI
PS C:\> gwmi win32_logicaldisk
Отмечу, что для Windows PowerShell не важен регистр — она знает, что у администраторов нет времени на всякую суету вроде нажатия клавиши Shift.
В результаты работы этой команды, показанные на рис. 2, входят все мои пять локальных дисков и их свойства FreeSpace, которые, как оказалось, приводятся выраженными в байтах. Кроме этого, выведено свойство DriveType для каждого из этих дисков, и на моем компьютере я вижу значения 2, 3 и 5.
Рис. 2 Все мои локальные диски и их свойства FreeSpace
Рис. 2 Все мои локальные диски и их свойства FreeSpace

Командлет месяца
Возможно, вы использовали Get-Content для чтения содержимого текстового файла. Он рассматривает каждую строку файла в качестве объекта [string] и передает эти объекты в конвейер для обработки другими командлетами. Но у Get-Content имеется ряд ключей, которые делают его более гибким: ключ –readCount, например, позволяет указать, какое количество объектов [string] передается в конвейер за один прием (по умолчанию передаются все), а ключ –totalCount управляет общим числом строк, считываемых из файла. Оба эти ключа удобны при работе с действительно большими файлами, когда из соображений производительности может возникнуть потребность отказаться от обработки всего файла за один прием.
Есть еще один ключ, который вы сочтете удобным. Ключ –encoding позволяет правильно читать обширный набор типов кодировки файлов, включая юникод, ASCII, UTF7, UTF8 и многие другие. Для просмотра полного списка поддерживаемых типов кодировки выполните команду help gc (gc — псевдоним для Get-Content).

Очистка данных
В этом пункте у меня две проблемы. Во-первых, мне не важны все прочие свойства, мне требуется только FreeSpace. Во-вторых, мне не нужна информация о свободном пространстве на оптических дисках, съемных дисках или сетевых дисках; меня заботят только локальные жесткие диски. Возможно, свойство DriveType поможет различить диски. Я возвращаюсь в веб-обозреватель и вижу, что в документации содержится таблица, поясняющая, чему соответствуют разные значения DriveType. Мне требуются те, которые имеют значение DriveType, равное 3, означающее, что это локальный жесткий диск. Хотя я никогда ранее не выполнял этого, решаю посмотреть, может ли команда Gwmi выполнить работу по фильтрации. Выполнив команду Help Gwmi –full, получаю подробные сведения о работе команды, включая несколько примеров. Обнаруживаю ключ, который кажется полезным, –filter, и поэтому решаю выполнить следующий вариант команды.
gwmi win32_logicaldisk -filter "drivetype = 3"
Сработало! Теперь в моем списке дисководов содержатся только локальные несъемные диски. Значит, вторая проблема решена; теперь необходимо разобраться с первой — избавиться от всех не интересующих меня свойств.
Запускаю Get-Command для получения списка всех командлетов Windows PowerShell и, в конце концов, наталкиваюсь на Select-Object. В описании сказано, что этот командлет «Выбирает указанные свойства объекта или набора объектов.» Поэтому я пытаюсь сделать следующее.
gwmi win32_logicaldisk -filter "drivetype = 3" | select freespace
Передавая по конвейеру результаты работы Gwmi в Select (псевдоним для Select-Object), я могу получить именно то свойство, которое мне требуется. Стоп, ошибочка вышла. Эти результаты не слишком хороши, поскольку все, что я получил, –– это список чисел — мне больше не известно, какое из перечисленных свободных пространств какому диску соответствует. Поэтому я возвращаюсь к документации и вижу, что свойство DeviceID содержит букву диска. Быстро переделываю свою команду и повторяю попытку.
gwmi win32_logicaldisk -filter "drivetype = 3" | select deviceid,freespace
Отлично! И, поскольку в списке имеются только два свойства, оболочке удается поместить информацию в аккуратную таблицу. (В следующем месяце я объясню, когда Windows PowerShell предпочитает списки, а когда — таблицы.)

Вычисления
Информация о свободном пространстве извлечена, но она представлена в байтах, а это в действительности не так удобно, как в мегабайтах или гигабайтах. Возможно, мне требуется не само свойство FreeSpace, а, скорее, значение, вычисленное на основе свойства FreeSpace. Командлет ForEach-Object (или один из множества его псевдонимов, например %) может с этим помочь. Этот командлет позволяет использовать специальную переменную, $_, для ссылки на текущий логический диск, что дает доступ ко всем свойствам диска по отдельности и позволяет выполнять некоторые математические операции. Далее идет измененная команда.
gwmi win32_logicaldisk -filter "drivetype = 3" | % { $_.deviceid; $_.freespace/1GB }
Я всего лишь удалил отсюда Select и заменил его псевдонимом для ForEach-Object (%). Этому командлету требуется только, чтобы ему сообщили, что следует сделать с каждым получаемым им Win32_LogicalDisk, и здесь указано, что требуется получить свойство DeviceID и пересчитать свойство FreeSpace в гигабайты — Windows PowerShell «знает», что такое KB, MB и GB, поэтому результат выдается в гигабайтах.

Несколько компьютеров
Теперь, когда эта процедура работает для одного компьютера, пора использовать ее для нескольких систем. Мне известно, как получить содержимое текстового файла. Это делается точно так же, как во времена MS-DOS® — с помощью команды Type, которая в Windows PowerShell, оказывается, является псевдонимом для Get-Content.
Type c:\computers.txt
Требуется сделать следующее — взять все эти компьютеры и для каждого из них выполнить уже разработанную команду WMI. Фраза «для каждого» должна напомнить вам о командлете — а именно, о ForEach-Object. Поэтому просто перейдем к завершающей демонстрации, как говорят в телевизионных шоу, обновляющих дома, и посмотрим на мою окончательную команду.
type c:\computers.txt | % { $_;
gwmi –computername $_ win32_logicaldisk -filter "drivetype=3" | % { $_.deviceid; $_.freespace/1GB} }
Ужасная, верно? Благодаря тому, что использовались исключительно псевдонимы, а не имена командлетов, прочесть это тяжело. Однако, это крайне просто расшифровывается, если ее разделить на маленькие порции.
  • Я начинаю с «печати» содержимого моего текстового файла.
  • Это содержимое передается по конвейеру в командлет ForEach-Object.
  • ForEach-Object выводит текущий результат с помощью переменной $_. (Это имя текущего компьютера.)
  • Затем ForEach-Object выполняет мою команду WMI, в которой содержится еще один вызов командлета ForEach-Object.
Замена имен-псевдонимов именами командлетов может облегчить понимание. Поэтому далее идет та же команда, но на этот раз написаны имена командлетов, и команда разделена на отдельные строки для удобства изучения каждого фрагмента.
Get-Content C:\Computers.txt |
ForEach-Object {
 $_; Get-WMIObject –computername $_
Win32_LogicalDisk -filter "DriveType=3" |
 ForEach-Object {
 $_.DeviceID; $_.FreeSpace/1GB
 }
}
Результаты, не будучи привлекательными, но оставаясь функциональными, показаны на рис. 3.
Рис. 3 Окончательные результаты
Рис. 3 Окончательные результаты

Нет необходимости в сценариях
Смысл этого анализа заключается в демонстрации использования Windows PowerShell без написания какого-либо сценария. Имея эти несколько примеров и изучив немного саму оболочку Windows PowerShell, вы действительно сможете найти те элементы, которые необходимы для выполнения любой поставленной вами задачи.
Итог состоит в том, что оболочка Windows PowerShell никуда не исчезнет. Может быть, уже сейчас стоит начинать учиться пользоваться ею? Возможно, вы будете удивляться, как до сих пор жили без нее — и, определенно, слово «сценарий» не удержит вас от того, чтобы приступить к ее использованию.

Дон Джонс (Don Jones) — ведущий разработчик сценариев в компании SAPIEN Technologies и преподаватель на ScriptingTraining.com. Связаться с Доном можно на его веб-узле по адресу ScriptingAnswers.com.


 Эй, сценарист!: Да будет Silverlight!
Эй, сценарист!
Да будет Silverlight!
Сотрудники группы Microsoft Scripting Guys
Загрузить исходный код для этой статьи: HeyScriptingGuy2007_10.exe (156KB)

История человечества полна примеров столкновений противоположных сил: римляне против полчищ варваров; Монтекки против Капулетти; Авторы сценариев против тех, кто полагает, что статья о написании сценариев системного администрирования должна рассуждать о написании сценариев системного администрирования, а не о, скажем, исторических столкновениях противоположных сил. [Или, скажем еще, о пирожках с мясом ... —Ред.]
Мир компьютеров тоже не защищен от таких вот столкновений. В частности, всякий помнит о борьбе между разработчиками и системными администраторами. Как однажды, изучив ситуацию, сказал Карл Маркс: «Либо этот человек мертв, либо у меня остановились часы».
Нет, постойте, виноват, это сказал все-таки Граучо Маркс. Карл Маркс сказал «Искусство – всегда и везде тайное признание, и в то же время – вечное движение своей эпохи». Честно говоря, у нас нет ни малейшего представления, чтобы это значило. Да и вообще, Граучо Маркс был куда веселее, чем Карл Маркс, даже несмотря на то, что остроты Граучо не имеют особого отношения к борьбе разработчиков с системными администраторами.
Тем не менее, мы вполне убеждены, что это именно Карл Маркс в свое время заставлял авторов сценариев наизусть повторять каждое утро перед работой торжественную клятву: «системные администраторы – не разработчики!». И вот это чистая правда: системные администраторы никогда не были разработчиками. Разработчики – это такие люди, которые пишут компьютерные программы, а системные администраторы – это такие люди, которые... ну, по правде, мы сомневаемся, чтобы кто-нибудь в Майкрософт в самом деле знал, чем были заняты системные администраторы. Но что бы это ни было, это точно не написание компьютерных программ.
И конечно, Карл Маркс еще написал песню «The Times, They Are A-Changing» («Времена – они меняются»). (Ну или, по крайней мере, он нам сказал, что написал ее.)
В частности, благодаря центру сценариев TechNet Script Center (microsoft.com/technet/scriptcenter) системные администраторы постепенно обнаружили такую штуку, как VBScript и начали писать собственные служебные программы, программы, которые хотя и не так полны и всеобъемлющи, как обычные компьютерные программы, все же выполняют полезные задачи управления. Создавая эти программы, системные администраторы вынуждены прибегать к приемам, весьма сходным с теми, которыми пользуются разработчики.
И это даже еще не верхняя половина айсберга. С приходом Windows PowerShell™ (microsoft.com/technet/scriptcenter/hubs/msh.mspx) Microsoft® .NET Framework перестает быть запретной зоной для системных администраторов и авторов сценариев. Windows Vista® представила мировой общественности мини-приложения (microsoft.com/technet/scriptcenter/topics/vista/gadgets-pt1.mspx), поставив системных администраторов – по крайней мере, тех из них, кто пишет сценарии, – в равные условия с разработчиками. А теперь (звучит барабанная дробь) на сцене весь в белом появляется Microsoft Silverlight, «кроссплатформенный подключаемый модуль для всех обозревателей, открывающий путь в следующее поколение основанных на .NET Framework возможностей использования мультимедиа и разнообразных интерактивных приложений в Интернете».
Впечатляет, не так ли? Но вы, быть может, спросите нас, какое все это имеет отношение к пишущим сценарии системным администраторам, вроде нас с вами? Честно говоря, мы и сами не знаем наверняка. Но с помощью Silverlight очень просто создавать очень привлекательные пользовательские интерфейсы и мультимедийные презентации. И хотя маркетинговые материалы упорно называют Silverlight способом создавать приложения для Интернета, есть одно малоизвестное обстоятельство: похоже, что Silverlight не хуже работает и для приложений HTML, или HTA (microsoft.com/technet/scriptcenter/hubs/htas.mspx), горячо любимых авторами сценариев. Так что попробовать Silverlight, может, и стоит.

Прежде чем мы продолжим...
Мы хотим отметить, что сегодня мы не собираемся обсуждать многочисленные возможности и использования Silverlight; наша главная задача – показать вам достаточно фрагментов кода, чтобы вы смогли сами начать баловаться с этой технологией. Если вы хотите установить Silverlight (это, кстати, бесплатно), зайдите на главную страницу Silverlight по адресу microsoft.com/silverlight. Разные пакеты SDK, примеры проектов и массу других полезных вещей можно найти по адресу silverlight.net/GetStarted.
А сейчас мы предположим, что вы уже установили Silverlight. Кроме того, мы предположим, что вы уже сходили в раздел загрузок кода на веб-узле журнала TechNet Magazine (technetmagazine.com/code07.aspx) и загрузили файлы, описанные на рис. 1.
Figure 1 Компоненты проекта Silverlight (Close Figure 1)

Файл | Описание
CreateSilverlight.js | Это сценарий JScript (в исходном выпуске Silverlight поддерживает только сценарии JScript), используемый для определения исходных параметров запуска Silverlight, включая XAML-файл, нужный для настройки пользовательского интерфейса и графических объектов.
SampleProject.js | Это просто чистый файл, где можно разместить функции JScript.
Silverlight.js | Этот файл используется для запуска управления Silverlight.
SampleProject.html | Здесь происходит все веселье. SampleProject.html – это просто HTML-файл, в котором есть код для чтения трех файлов.js. Также в нем есть код для создания экземпляра элементов управления Silverlight.
SampleProject.xaml | А это зачем? Чтобы это узнать, придется вернуться в основной текст статьи.
Файл SampleProject.js не обязательно нужен, по крайней мере для того, чтобы читать статью за этот месяц. Silverlight позволяет присоединять сценарии к объектам и событиям в вашем проекте; эти сценарии можно либо прямо закодировать в свой HTML-файл, либо (как в нашем случае) прочитать их из внешнего файла «include» (включить) вроде этого. А еще мы превратим файл SampleProject.html в HTA: просто переименуйте его в SampleProject.hta. Просто, правда?
Теперь сохраните все эти файлы в одну папку. И приготовьтесь – сейчас будет весело!

XAML-файл
Как вы уже могли догадаться, все самое интересное в этой рубрике «Эй, сценарист!» связано с XAML-файлом. (Так получилось, что XAML произносится «замель» и рифмуется с «глазами». Или «низами». Или даже «железами».) XAML – это сокращение от Extensible Application Markup Language. Помимо прочего, XAML позволяет создавать пользовательские интерфейсы с помощью языка, похожего на XML. Становится ли от этого легче кому-то – системному администратору, если быть точным – создавать пользовательские интерфейсы? Сейчас вы все узнаете.
Чтобы начать это увлекательное приключение, запустите программу «Блокнот» и откройте файл SampleProject.xaml. Если там есть какой-нибудь код, замените его таким:
<Canvas
 xmlns="http://schemas.microsoft.com/
    client/2007"
 xmlns:x="http://schemas.microsoft.com/
    winfx/2006/xaml">
</Canvas>
Примечание. SampleProject.hta уже заранее настроен так, что загружает информацию из SampleProject.xaml. Для использования другого XAML-файла придется подправить файл CreateSilverlight.js.
Скопировав код, сохраните файл и дважды щелкните SampleProject.hta. Догадались, что там будет? Точно! Большое скучное серое окно.
Да подождите, ну куда же вы! Именно это там и должно быть.
Все это выглядит не очень здорово потому, что мы еще ничего не сделали: все, чего мы пока что добились -- мы добавили в наш XAML-файл Canvas (холст). Но это важный шаг. В конце концов, если вы соберетесь писать маслом, то в первую очередь вам понадобится холст. То же самое и с Silverlight: прежде, чем мы сможем добавлять в свой проект элементы, нам нужен холст, на котором мы будем «рисовать». И теперь он у нас есть.
Кстати, почему мы получили серое окно размером 300 на 300 пикселов? Все просто: таковы параметры по умолчанию в файле CreateSilverlight.js. Если они вам не нравятся, просто откройте CreateSilverlight.js и настройте их по вкусу. Не хотите ли белый холст 800 пикселов шириной и 300 пикселов высотой? (А для тех примеров, которые мы будем приводить, именно такой вы и хотите.) Тогда просто убедитесь, что у вас в CreateSilverlight.js есть три такие строки:
width:'800', // Width of rectangular region of
             // control in pixels.
height:'300', // Height of rectangular region
              // of control in pixels.
background:'white', // Background color of
                    // control.
Примечание. Стоит заметить: в оригинальном файле .js фон имеет значение #D6D6D6. Теперь мы сделали его белым (white). Оказывается, что в XAML-файле можно использовать для обозначения цветов как значения RGB, так и названия цветов. (Полный список значений и названий цветов есть по адресу msdn2.microsoft.com/bb188314.aspx.) И хотя мы, сценаристы, больше всего любим называть цвета значениями RGB («Мой дом? Он FFFFFACD с FFCD5C5C отделкой»), мы решили использовать здесь названия цветов.
Бесплатный совет: в качестве фона не обязательно использовать только один цвет. Скопируйте код с рис. 2 в свой XAML-файл и посмотрите, что получится.
Figure 2 Красивые цвета (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Попробовали? Здорово, да?
Конечно, чистый холст сам по себе не то чтобы слишком интересен. Поэтому давайте добавим на этот холст какой-нибудь объект. Хотя Silverlight позволяет добавлять самые разные объекты (в том числе эллипсы, прямоугольники, прямые и даже, удивительное дело, многоугольники), мы добавим на свой холст старое доброе проверенное текстовое поле. Как? Вставив в наш XAML-файл между тегами <Canvas> и </Canvas> следующие теги:
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">
</TextBlock>
Как видите, вся эта тема с XAML – это не так и трудно. Мы начали с использования тега <TextBlock>, не забыв включить в него разные параметры TextBlock (наподобие Name и FontSize). Затем мы говорим, что закончили с этим TextBlock, с помощью тега </TextBlock>. Что в этом такого хорошего? То, что примерно так же в XAML-файл добавляется любой другой объект. Хотите прямоугольник в 300 пикселов шириной и 100 пикселов высотой? Никаких проблем:
<Rectangle
 Height="300"
 Width="100"
 Fill="Blue">
</Rectangle>
К слову, добавляя на холст фигуру (вроде прямоугольника), не забудьте указать цвет Fill (заливки) и/или цвет Stroke (штриха). Если этого не сделать, Silverlight добавит на холст прозрачный прямоугольник. Прямоугольник там будет, но вы его не увидите, если у вас, конечно, не какое-нибудь там магическое рентгеновское зрение.
Собственно, о цветах Fill и Stroke: именно с их помощью раскрашиваются некоторые объекты Silverlight. Для других объектов понадобится кисть, вроде LinearGradientBrush, которую мы показали (но о которой не рассказали) в бесплатном совете. Если вам хочется раскрасить объекты одним цветом, можно взять кисть с оригинальным названием SolidColorBrush. Например, посмотрите на теги XAML на рис. 3, которые «красят» наш текст (с технической точки зрения, окрашивается параметр TextBlock Foreground) в красный.
Figure 3 Раскраска текста (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Чтобы получилось еще веселее, попробуйте функцию ImageBrush, которая заполняет текст картинкой:
<TextBlock.Foreground>
 <ImageBrush Name="test_brush" ImageSource="Sunset.jpg"/>
</TextBlock.Foreground>
А вот и еще подсказка: если вы используете ImageBrush, то наверняка хотите увеличить значение FontSize, потому что чем больше текст, тем лучше эффект.
Попробуйте и посмотрите, что получится. Вы будете впечатлены пропорционально.

Но подождите. Вы еще ничего не видели
Нам нужно уравнять положение: пока что все самое вкусное мы оставляли себе. То, что в Silverlight можно отображать текст – это здорово; еще лучше то, что можно рисовать прямоугольники, эллипсы и многоугольники. Но все это меркнет по сравнению с анимациями, которые можно добавить в проект Silverlight.
Опять же, все, что мы можем сделать в этой статье, – это показать вам пару способов создавать анимацию в Silverlight; у нас просто нет места на большее. (Не судите нас строго; мы все время предлагаем переименовать журнал TechNet Magazine в журнал Hey, Scripting Guy! Magazine, но наши письма, видимо, не доходят куда надо.)
Без дальнейших проволочек, вот отличный эффект, от которого наш текст медленно (но верно) станет более четким. Добавьте код с рис. 4 между тегами <TextBlock> и </TextBlock> в своем XAML-файле.
Figure 4 Приемы работы с TextBlock (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Надо признать, это выглядит так, как будто тут в крупных размерах происходит какая-то чепуха; к счастью, большинство этого – просто заготовка. Во-первых, нельзя просто добавить в XAML-файл анимацию; нужно указать, когда она должна сыграть. Для этого придется указать набор триггеров (Triggers) для TextBlock. В нашем случае мы создадим триггер, запускающий анимацию всегда, когда загружается TextBlock:
<EventTrigger RoutedEvent="TextBlock.Loaded">
В Silverlight анимации происходят по раскадровке (Storyboard) (термин позаимствован из кино). Поэтому есть теги <BeginStoryboard> и <Storyboard>.
Чтобы текст проявился, нужно изменить свойство Opacity (непрозрачность). Мы постепенно увеличим это значение с 0.0 (прозрачный) до 1.0 (сплошной цвет). Так как Opacity оказалось по стечению обстоятельств свойством типа Double (свойством, основанным на числовом значении двойной точности), мы используем анимацию DoubleAnimation. А как, спросите вы, мы используем анимацию DoubleAnimation? Ну, просто, указав объект, из которого мы делаем анимацию (в нашем случае Test, имя, присвоенное TextBlock); определив целевое свойство (Opacity); и затем указав и диапазон анимации (от непрозрачности 0.0 до непрозрачности 1.0) и продолжительность всей анимации (5 секунд). Другими словами:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
Примечание. Обязательно используйте синтаксис 0:0:5 (часы, минуты, секунды), чтобы указать 5 секунд. Если взять просто значение 5, ошибки не будет, но анимация займет 5 дней.
Попробовали? А теперь попробуйте вот это: в теге DoubleAnimation установите значение параметра AutoReverse на True:
AutoReverse="True"
Анимация сперва проявит текст, а потом он снова поблекнет.
Установите значение параметра RepeatBehavior на Forever (навсегда) и текст продолжит проявляться и исчезать... ну, до конца времен:
RepeatBehavior="Forever"
Или навсегда – это долговато? Тогда пусть RepeatBehavior будет, скажем, 3x, и анимация повторится 3 раза и прекратится.
RepeatBehavior="3x"
Все это очень здорово, мы сами так все время говорим. Но что, если вам не нравится текст, который то появляется, то исчезает? Что если вы предпочитаете текст, который постепенно меняет цвет? Что ж, тогда нужно воспользоваться анимацией ColorAnimation:
<ColorAnimation
 Storyboard.TargetName="test_brush"
 Storyboard.TargetProperty="Color"
 From="Red" To="Blue" Duration="0:0:5" />
Примечание. Начните пробовать это с нашего красного текста. Ведь помните, мы уже показали, как сделать текст красным.
Правда, увлекательно? Но вы, кажется, разочарованы. Ага, и вот почему: ColorAnimation – это замечательно, но вы ведь на самом деле надеялись, что предметы будут летать по всему экрану. Эй, не падать духом! Какой программой была бы Silverlight, если бы с ее помощью нельзя было заставить предметы летать по экрану?! Попробуйте следующее:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Left)"
 To="150"
 Duration="0:0:5" />
Как можно видеть, мы заставили наш TextBlock медленно переместиться с исходной позиции в точку на 150 пикселов левее края холста (Canvas.Left). Если бы мы хотели, чтобы TextBlock двигался вверх-вниз, мы бы просто использовали параметр Canvas.Top:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Top)"
 To="150"
 Duration="0:0:5" />
А не можем ли мы—сердце уходит в пятки—совместить эти анимации и заставить TextBlock двигаться и вбок и вверх-вниз? Это выше нашего понимания. Но вот подсказка: скопируйте обе анимации в свой XAML-файл (прямо друг за другом) и посмотрите, что из этого выйдет.
Примечание. Ну да, мы вас надули. Мы с самого начала знали, что можно совместить эти анимации. По сути, в один проект Silverlight можно натолкать целую стопку анимаций. Это чуть сложнее — возможно, понадобится добавить дополнительные теги, чтобы одна анимация заканчивалась до того, как начнется следующая. Но зато это дает возможность создавать всякие необычные анимации, просто набрав пару тегов, похожих на XML.

Простите, друзья; представление окончено
Да, мы понимаем. Нам тоже не хочется заканчивать, особенно когда мы начали подбираться к действительно интересным штукам. Но не беспокойтесь; мы не прощаемся навечно. Если вы хотите узнать больше о Silverlight, напишите нам по адресу scripter@microsoft.com. Если будет много интересующихся, что ж, хорошо, мы посмотрим, нельзя ли сделать что-нибудь в будущих статьях. Конечно, не забывайте также заглянуть в центр сценариев TechNet Script Center (microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx); мы разместим для вас ссылки на полные примеры XAML (экXAMLяры?). А до тех пор, как говорили Карл Маркс и Фридрих Энгельс в конце своего манифеста в письме с Брюссельского коммунистического корреспондентского комитета Г.А. Коттгену, «Спокойной ночи и, пожалуйста, будьте аккуратны за рулем по дороге домой».

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


 На страже безопасности: BitLocker и сложности доверия
На страже безопасности
BitLocker и сложности доверия
Джастин Траутмэн (Justin Troutman)

Windows Vista. Я впервые использую эти два слова в статье, поэтому напоминаю себе пятилетнего ребенка, который гуляет по магазину игрушек с чеком, в котором не проставлена сумма покупки. Тут можно о многом поговорить, многое исследовать, развить обсуждения по огромному количеству вопросов.
Некоторое время тому назад я читал блог гуру по безопасности Брюса Шнайера (Bruce Schneier) и наткнулся на нечто, что для меня в тот момент было совершенно новым – BitLocker™. Я быстро понял, что эта функция предназначалась для криптографических возможностей Windows Vista®—и тут же напрягся – «О нет, Windows Vista занимается криптографией? Вряд ли это приведет к чему-то хорошему. И даже если что-то и получается, наверняка где-то есть проколы.»
Существует некоторое количество исторических аргументов (подтвержденных или нет) относительно того, почему не стоит полагаться на функции безопасности, встроенные в Windows®. Но я пишу эту статью по другой причине. Я, напротив, хочу подробно рассказать о том, почему я думаю, что существует ряд причин дать BitLocker шанс. Также я бы хотел сказать пару слов о философии, обеспечивающей жизнеспособность криптографического программного обеспечения и оборудования.
Но не надо ошибаться: Я не предлагаю BitLocker в качестве панацеи для всех вопросов безопасности – BitLocker всего лишь один из кусочков головоломки безопасности. Его целью является обеспечение отказоустойчивости при определенных моделях угроз.
Например, BitLocker очень хорошо подходит для случаев с пропавшими (или украденными) портативными компьютерами. Мобильные пользователи постоянно носят с собой различную конфиденциальную информацию – в поездах и самолетах, ресторанах и отелях, домашних офисах и филиалах компаний. Эта информация хранится на их портативных компьютерах и других мобильных устройствах, которым зачастую не хватает настоящей защиты, что ставит под угрозу хранящиеся на них данные. Так что происходит с данными, если один из ваших пользователей оставит где-нибудь свой портативный компьютер?
Если человек небрежен, это очень сложно исправить. К счастью, можно свести к минимуму неприятности, которые с этим связаны. Компания понесет значительно меньшие убытки при замене портативного компьютера в сравнении с убытками при раскрытии конфиденциальной информации. Именно для обеспечения этого вида безопасности и предназначен BitLocker.

Сомнения в достоверности
Здесь я хочу обсудить BitLocker с интересной точки зрения. Дело в том, что я сам еще не проводил испытания этой программы. Я знаю, что вы можете подумать: как человек, который даже не использовал BitLocker, может судить о нем и уж тем более сказать что-то ценное? Прошу вас потерпеть. На самом деле я собираюсь обсудить криптографию с более высокого уровня, а также философии разработки, необходимые для успешного решения проблемы.
Все началось с моего прочтения блога Брюса Шнайера. Предположим, вы хотите посмотреть новый фильм. Вы строите некоторые предположения о фильме на основе рекламного ролика и актерского состава. Разумеется, хороший актерский состав не может гарантировать то, что и фильм будет хорошим. Однако, он может многое сказать о фильме и о том, что можно от этого фильма ожидать. Кто там снимается – Крис Рок и Бен Стиллер? Или Кейт Уинслет и Джонни Депп?
Точно так же, когда я вижу, как известный и уважаемый в международном масштабе гуру безопасности обсуждает в своем блоге BitLocker, я могу сделать ряд предположений. Для начала я предполагаю, что эта новая технология либо достаточно хороша, чтобы заслужить его упоминание, либо настолько плоха, что он хочет сообщить об этом всем. К моему удивлению, окончательный вердикт Брюса Шнайера был положительным.
Одно предложение в его записях выделялось особо: «У этой системы нет обходных путей». Это довольно сильное заявление. Оно выглядело очень уверенно и включало в себя ссылку на блог группы Microsoft®, занимающейся целостностью систем. Я воспользовался этой ссылкой и нашел высказывания Нильса Фергюсона (Niels Ferguson), разработчика программ безопасности корпорации Майкрософт, отрицающего слухи о том, что Майкрософт специально предусмотрел обходные пути в BitLocker для правоохранительных органов. Фергюсон прямо заявил, что обходные пути неприемлемы, и он не будет участвовать ни в одном проекте, который их поддерживает. (Он также объяснил, что даже если бы корпорация Майкрософт была вынуждена включить обходные пути по настоянию правоохранительных органов, она либо объявила бы об этом публично, либо же вовсе отказалась от этой функции.)
Имя автора – Нильс Фергюсон – объясняет уверенность Шнайера и передает эту уверенность и мне. Фергюсон – человек, который знает, о чем говорит, а его репутация свидетельствует о том, что его словам можно доверять. Брюс Шнайер и Нильс Фергюсон являются авторами книги «Практическая криптография» (основополагающего труда по применению хорошей криптографии, просто, правильно и безопасно), а также разработчиками блочного шифра, Twofish – 128-разрядной сети Feistel, которая заслужила признание в криптоанализе, став финалистом процесса отбора AES (Advanced Encryption Standard, улучшенного стандарта шифрования).
Разумеется, даже если к проекту добавлен надежный криптограф, нет гарантии, что окончательная версия продукции будет безопасной. Даже мастера этого дела иногда могут сделать пару промахов. Однако, вне зависимости от успехов BitLocker, вы можете, по крайней мере, быть уверены, что в его создании были задействованы надежные стратегии проектирования.
Говоря о промахах, существуют добросовестные попытки, предпринимаемые разработчиками, ничего не смыслящими в криптографии, и недобросовестные попытки тех, кто наиболее заинтересован в том, чтобы как можно быстрее выпустить продукцию. Обе попытки, вне зависимости от намерений, не решают проблемы безопасности. Вышесказанное, тем не менее, не относится к BitLocker. В этом случае удачу предвещает участие в процессе хотя бы одного компетентного криптографа и достаточных ресурсов, поддерживающих проект.

Несколько слов о доверии
Не так давно Фил Циммерман (Phil Zimmerman), создатель шифрования PGP, поделился со мной несколькими практическими методами. Если бы когда-нибудь был опубликован труд под названием «Принципы безопасности для разработчиков», его советы наверняка были бы самыми ценными. Хотя они и не относятся конкретно к BitLocker, но философии проектирования, на которых они основаны, могут применяться к практически любому криптографическому решению. Возможно, вам они покажутся очевидными или чересчур навязчивыми. Однако, учитывая текущее положение вещей с безопасностью, о них стоит упомянуть отдельно.
При разработке криптографической инфраструктуры разработчик должен использовать простые, правильные и безопасные методы. Хотя ошибок избежать все равно не удастся, они не должны восприниматься как нечто естественное и попросту сбрасываться со счетов. Разработчик должен твердо придерживаться принципа самых высоких требований. Циммерман советует «работать так, как если бы одна ошибка стоила кому-нибудь жизни». Думаете, это преувеличение? На ежегодной конференции по компьютерной безопасности в 2005 году NSA криптограф Брайан Сноу (Brian Snow) (ныне находящийся на пенсии) сказал: «Устройство, отвечающее за безопасность, должно быть функционально и надежно. Мы не проводим бета-тесты на клиентах. Если моя продукция не будет работать должным образом, кто-нибудь может умереть.» Запомните – ошибки могут повлечь за собой не только денежные расходы.
Пользователи заслуживают гарантии надежности. Доверие пользователей необходимо заслужить – и поддерживать. Циммерман заявляет об этом весьма четко: «Заслужите доверие пользователей. Как только вы возьмете на себя эту ответственность, вы уже не сможете сложить ее с себя». Таким образом, компания дает пользователям гарантию и поддерживает свою репутацию надежного производителя. В случае утраты репутации ее практически невозможно восстановить.
Я надеюсь, корпорация Майкрософт учитывала эти принципы при разработке BitLocker (или любой другой продукции, относящейся к этой области). Вышесказанным я хотел объяснить, почему я думаю, что Майкрософт все сделала правильно и создала технологию шифрования, которую следует воспринимать серьезно.

Простой человек и его слон Elephant
По сути BitLocker – это то, как Windows Vista (и особенно выпуски Enterprise и Ultimate) шифрует все данные системного тома. Это приложение может показаться весьма незамысловатым, но необходимо учитывать ограничения. Поскольку BitLocker шифрует данные по каждому сектору, а шифрованный текст не может быть больше открытого текста, практически не остается места ни для чего другого – например специальных данных (числа или строки, используемых только один раз для проверки подлинности), вектора инициализации (IV) или кода проверки подлинности сообщений (MAC). Я предвидел вероятность появления таких ограничений и условий, которые они накладывают, но я также знал, что проблема проверки подлинности сообщений не будет выпущена из виду.
BitLocker полагается на то, что часто называют упрощенной проверкой подлинности. Компромисс не так консервативен, как вам бы хотелось, поскольку предполагает, что шифрованный текст после обработки будет представлять собой бессмысленный открытый текст. Другими словами, если шифрованный текст будут обрабатывать, он скорее вызовет сбой системы, чем позволит конкуренту добиться выполнения каких-либо функций.
Группа Майкрософт, занимавшаяся BitLocker, знала, что совершенно новый блочный шифр потребует больше времени для анализа, чем это приемлемо, однако существующие разработки либо не были достаточно хорошо изучены, либо оказались недостаточно эффективными. Поэтому для шифрования Майкрософт выбрала AES в режиме CBC (цепочки шифрованных блоков), который я буду называть AES-CBC. Этот шифр неотличим для выбранной модели атаки с открытым текстом (сокращенно IND-CPA), но не сохраняет целостности. А поскольку нет места также и для MAC, а CBC – это режим конфиденциальности, то можно говорить о полном отсутствии сохранения целостности. По этому сигналу в нашу посудную лавку входит слон Elephant.
Новый компонент Elephant содержит два диффузора, разработанных для обработки существенно лучшей упрощенной проверки подлинности, чем чистый AES-CBC. (Должен, тем не менее, отметить, что возможно применение AES-CBC без Elephant для тех, кто должен придерживаться строгих политик соответствия стандартам.) Хотя упрощенная проверка подлинности не всегда является идеальной, она предлагает наиболее подходящее решение в условиях существующих ограничений, а Elephant призван использовать ситуацию по максимуму. Каким образом все это работает?
На рис. 1 приведен порядок понимания. При шифровании открытый текст при помощи XOR объединяется с ключом сектора. Затем текст проходит через два диффузора без ключей. После этого текст шифруется при помощи AES-CBC. Ключ сектора и AES-CBC требуют ключевой материал и, таким образом, оба получают ключи – независимо друг от друга. Этот метод упрощает формализацию проверки сокращения безопасности конструкции AES-CBC и Elephant по сравнению с AES-CBC. Elephant – это новый базовый элемент, а новые элементы обычно вызывают недоверие до тех пор, пока они тщательно не проанализированы. Этот подход, тем не менее, уравновешивает весы, поскольку BitLocker может показать, что AES-CBC с Elephant атаковать не намного легче, чем AES-CBC без него.
Рис. 1 Упрощенная проверка подлинности с использованием Elephant
Рис. 1 Упрощенная проверка подлинности с использованием Elephant
Ключ сектора и компоненты AES-CBC оба получают 256 битов ключевого материала, увеличивая длину ключа до 512 битов. По умолчанию эти компоненты используют только 128 битов ключевого материала каждый, что означает, что некоторый ключевой материал не используется. Причиной этого является то, что гораздо легче выбросить биты, которые вам не нужны, чем изменить инфраструктуру управления ключами по мере изменения длины ключа.
Длиной блока может стать любая степень двойки, в пределах от 512 до 8192 битов. Для того, чтобы гарантировать, что любое изменение результатов шифрованного текста приведет к случайным изменениям во всем открытом тексте сектора, блок шифрования создан для работы с изменяющимся размером блока. Более того, если он будет вести себя как настраиваемый блочный шифр (как описывают Лисков, Ривест и Вагнер) с несколько изменяющимся от сектора к сектору алгоритмом, оппонент не сможет успешно перенести шифрованный текст из одного сектора в другой.

Время покажет
Размышления о криптографической безопасности BitLocker могут увести в сторону от более масштабной проблемы. Надежность BitLocker не обязательно означает, что он будет в состоянии выполнять свою работу. Причиной этого является то, что BitLocker – не отдельная программа, а лишь одно из многих дополнений Windows Vista. Майкрософт заявляет, что BitLocker плотно интегрирован в Windows Vista. Однако, если существует такая плотная интеграция с операционной системой, не означает ли это, что сбой в работе одного из компонентов может привести к сбою или снижению надежности BitLocker?
Лично я верю в модульный принцип и изолированные сбои. Плотная интеграция без модульного принципа приведет к осложнениям. Разумеется, этого может не произойти с Windows Vista и BitLocker, однако только время – и подробный анализ – покажет, так ли это на самом деле.
Так что я думаю о BitLocker? Я снимаю шляпу перед группой Майкрософт, занимающейся целостностью систем, за работу с надежными криптографами, которые четко выполняют свои обязанности. Совершенно очевидно, что эта функция была разработана для шифрования, а не для маркетинговой кампании. Поэтому я заявляю, что BitLocker следует воспринимать серьезно. Я не говорю о том, является ли он действительно надежным. Это будет ясно только со временем и по результатам применения. Многие элементы шифрования и протоколы были взломаны. Но, по крайней мере, группа целостности систем Майкрософт дала нам понимание и платформы, на которых можно создать более совершенные решения.

Джастин Траутмэн (Justin Troutman) – набирающийся опыта криптограф и аспирант-математик. Основной упор в своих работах он делает на симметричную криптографию. Он также является создателем компании Extorque, специализирующейся на криптографических исследованиях и консультациях.


 Материалы о рабочей среде: Руководство квалифицированного пользователя по WIM и ImageX
Материалы о рабочей среде
Руководство квалифицированного пользователя по WIM и ImageX
Уэс Миллер (Wes Miller)
Этот выпуск рубрики основан на предварительной версии пакета автоматической установки Windows (Windows Automated Installation Kit – WAIK) и Windows Server 2008. Любая информация, содержащаяся в нем, может быть изменена.

В нескольких из числа предыдущих выпусков я рассказывал о ImageX и формате Windows Imaging (WIM). На конференции Tech•Ed несколько месяцев назад мне довелось услышать некоторые комментарии и вопросы специалистов по ИТ, начинающих использовать службы развертывания Windows (WDS), ImageX и пакет автоматической установки Windows (WAIK), и я осознал
необходимость более подробного их освещения. Так что нынешней выпуск моей рубрики я решил посвятить ImageX, формату WIM и тому, как их можно использовать с наибольшей пользой. Вместе ImageX и WIM позволяют легко развертывать не только Windows Vista® и Windows Server® 2008, но также Windows® XP, Windows Server 2003, и Windows 2000.

Изменения в WAIK
Предстоящий выпуск Windows Server 2008 может заставить задуматься о том, что он означает для WAIK. Корпорация Майкрософт планирует выпустить обновленную версию WAIK в тех же временных рамках, что и Windows Server 2008. Формат WIM не претерпел существенных изменений (средство ImageX и формат остались прежними); служба WDS для Windows Server 2003 также не изменилась. Вопреки слухам, многоадресные запросы не будут доступны для служб развертывания Windows Server 2003 – только серверы служб развертывания, работающие под Windows Server 2008, получат новую возможность многоадресности для WDS.
Windows PE 2.0 и программа установки Windows будут пересмотрены в целях поддержки следующих возможностей:
  • Развертывание Windows Server 2008 и Windows Vista.
  • Многоадресное развертывание через WDS с сервера развертывания под управлением Windows Server 2008.
  • Развертывание версий x64 наравне с версиями x86 систем Windows Vista и Windows Server 2008 с версии x86 Windows PE.
В первую очередь это значит, что Windows PE 2.0 сможет развертывать Windows Server 2008 так же легко, как и Windows Vista, – те же средства и процедуры работают одинаково хорошо для обеих. Во-вторых, появится возможность многоадресного развертывания через WDS после перевода серверов развертывания на Windows Server 2008. Наконец, это значит, что можно будет использовать диск x86 Windows PE 2.0 для развертывания с него образа как x86, так и x64 версий Windows.
Я упомянул последний момент на конференции Tech•Ed, когда рассказывал о версии x64 Windows. Увы, в блогах и техническом сообществе Windows возникла некоторая путаница по этому вопросу. Это не значит, что Майкрософт будет распространять x64 Windows и x86 Windows на каждом диске DVD с Windows Vista или Windows Server 2008. Это также не значит, что образы Windows x64 и Windows x86 следует совмещать в единый файл WIM (хотя это возможно). Это не дает никакого выигрыша в объеме за счет хранения одного экземпляра, хотя и позволяет передавать WIM как один файл.
Это значит, что корпоративные клиенты и производители оборудования, годами разрабатывавшие процессы развертывания на основе x86 (а также собственные сценарии и средства), теперь смогут развертывать как x86, так и x64 версии Windows из WIM, используя 32-разрядную программу установки – запрос, выдвигавшийся корпоративными клиентами, начиная с первого появления x64 версий Windows в 2005 году.

Повседневный ImageX
Использование /mount, /mountrw и /delete
Вот несколько важных советов по использованию ключей /mount, /mountrw и /delete в программе ImageX:
  • Подключите том с помощью /mountrw, если собираетесь его править.
  • Файл WIM следует подключать к пустому каталогу, чтобы не возникло путаницы с хранящимися там файлами, а ImageX не выдавал бы ненужных предупреждений.
  • Не забывайте применить /unmount /commit к образу в режиме чтения и записи, если хотите сохранить сделанные изменения. Слишком часто я забывал зафиксировать свои изменения (и, естественно, терял их).
  • Удаление файлов с помощью /mountrw и удаление образов тома с помощью /delete не освобождает пространства – на самом деле, может даже занять его еще больше. Подробности приведены в этой рубрике в разделе, посвященном /export.
  • Одновременно для чтения и записи может быть подключен только один WIM-файл. Двое пользователей не могут править один и тот же WIM-файл одновременно, также нельзя править два образа тома одновременно.
  • Даже в режиме «только чтение» (/mount) следует ограничивать число одновременно установленных образов тома, поскольку драйвер зависит от размера невыгружаемого пула памяти Windows, доступного для каждого установленного образа. Это приводит к ограничению, которое может варьироваться в зависимости от системы (или ее архитектуры). Я не рекомендовал бы использовать более пяти образов одновременно.
  • Проведение значительных правок с помощью /mountrw почти не занимает времени собственно при внесении изменений, но может привести к уходу значительного объема времени на /commit, поскольку ему необходимо сжать и сохранить все новые данные файлов.
  • Используйте /delete и /mountrw осторожно – после фиксации изменений их невозможно отменить.
  • Запуск /delete невозможен, если в WIM-файле имеется только один образ тома (вместо этого удалите весь WIM-файл или добавьте новый образ тома).
  • Чтобы быстро получить дерево каталогов содержимого образа тома, используйте вместо /mount следующую команду:
ImageX /dir <path_to_wim_file> <image index>
  • При одновременной правке двух WIM-файлов старайтесь не применять /unmount к ним одновременно; спланируйте последовательность событий mount/unmount так, чтобы они не блокировали одно другое.

ImageX был специально разработан для отражения способов, которыми разработчики оборудования и корпоративные клиенты, по их словам, используют подобные средства. На рис. 1 приведен пример соответствующей процедуры.
Рис. 1 Использование ImageX
Рис. 1 Использование ImageX
Стоит особо отметить, что Этап 5 крайне важен – истина заключается в том, что образ постоянно меняется. Таким образом, запись и изменение образа должны быть максимально быстрыми и простыми.
С этой целью можно добавить еще один образ (при помощи ключа /append) к уже созданному. Первоначально группа разработчиков полагала, что пользователи будут добавлять дополнительный SKU (версию Windows) к предыдущему образу, но чем больше я работал с корпоративными клиентами на ранних этапах разработки Windows Vista, тем больше слышал о ее использовании для быстрого развертывания X, а затем быстрой повторной записи X1, где делалось одно из изменений на этапе 2. Это делало возможным быструю повторную запись образа, поскольку изменения вносились лишь в ограниченное число файлов.
Когда разработчики поняли это, они осознали, что сохранение исходного образа имеет смысл не во всех ситуациях. Дальше в рубрике я расскажу о ключе /export, добавленном специально для этой ситуации, а также о том, что следует дальше.

Изменение постоянно
На раннем этапе группа разработчиков решила, что файлы WIM должны быть редактируемыми. Поскольку еще раньше они решили, что посекторный формат образов не будет работать (объяснения приведены в выпуске рубрики за декабрь 2006 г. на technetmagazine.com/issues/2006/12/DesktopFiles), им нужно было предоставить решение, которое легко подключало бы файлы непосредственно как часть файловой системы Windows и вносило бы изменения в подключенные образы томов в WIM-файле. Это означало некоторое увеличение числа того, что я называю «движущимися частями». Подключение образа на основе секторов реализуется сравнительно просто, но подключение закрытого архивного формата вроде WIM требовала очень специального набора средств.
К формату должен был существовать доступ из командной строки – что исключало использование обычных расширений оболочки Windows, используемых для обработки файлов ZIP и CAB встроенными средствами. Увы, эти обработчики дают проводнику Windows лишь абстрактный доступ к объекту.
Как следствие этого, решение WIM включает в себя драйвер (wimfltr.sys) и программу ImageX, служащую методом действительной загрузки драйвера и предоставляющую интерфейс для подключения файлов WIM. Драйвер предназначен для добавления абстракции в файловую систему Windows, как показано на рис. 2. Запуск подобной команды означает указание программе ImageX загрузить драйвер wimfltr.sys и заставить драйвер наложить первый образ тома (номер 1 в командах, используемых здесь) на точку подключения в пустом каталоге, как показано ниже:
Рис. 2 Установка образа тома WIM
Рис. 2 Установка образа тома WIM
ImageX /mount iso\sources\boot.wim 1 mount
ImageX /mountrw iso\sources\boot.wim 1 mount
Это поведение по умолчанию в WAIK. Таким образом, при исследовании или выводе содержимого каталога для каталога подключения корень образа диска 1 появится в boot.wim. Само собой, использование /mountrw или /mount будет определять, предназначен ли каталог только для чтения или для чтения и записи (подробности приведены на боковой панели "Использование /mount, /mountrw и /delete").
Возможность /mountrw была изначально разработана для легкого добавления драйверов или иных копируемых в составе каталогов файлов и содержимого, установки файлов ответа либо правки автономного реестра установленного WIM-файла для изменения его по мере надобности (см. рис. 3). Она не предназначалась для добавления или удаления целых приложений (поскольку установщик Windows не может устанавливать приложения при работе в автономном режиме).
Рис. 3 Правка установленного WIM-файла
Рис. 3 Правка установленного WIM-файла
Очень важно понять, что при внесении изменений в установленный WIM-файл сам он не изменяется напрямую (по крайней мере, изменяется не сразу); вместо этого изменяется кэш WIM-файла, который на самом деле является слиянием наложения и сделанных пользователем изменений. Как я отметил на боковой полосе, мне ранее случалось наступать на эти грабли. Не забывайте использовать ключи /unmount и /commit по окончании работы, поскольку лишь в этом случае внесенные изменения будут зафиксированы в WIM-файле. В противном случае они будут целиком утеряны.
Когда изменения сохраняются путем их фиксации, вы указываете драйверу изменить сам WIM-файл. Драйвер добавляет дополнительные данные файлов. (Заметьте, что если было сделано много изменений, /commit может занять значительный объем времени, поскольку данные реально добавляются в WIM только в этот момент.)
Также, в отличие от посекторного формата образов, могут измениться один или несколько файлов в образе тома. Как результат, они больше не будут единственными экземплярами (если этот же файл уже не был однажды сохранен), и исходные данные файлов окажутся утеряны. WIM, в отличие от томов NTFS или FAT, не помечает файл как удаленный – он больше не ссылается на него, но не стирает его. Как следствие, при частых правках с помощью /mountrw или добавки многочисленных образов через /append, а также использования /delete для удаления образа тома WIM-файл забывает ссылки на файловые данные, но не сбрасывает эти данные окончательно.
Поэтому группа разработчиков и создала ключ /export, также известный как своего рода «дефрагментатор WIM».

Экспортирование
Важные замечания насчет /export
Когда /export используется для создания нового WIM-файла, можно указать нужный тип сжатия данных вместо использования текущего типа по умолчанию. При изменении текущего типа сжатия экспортирование может занять значительное время.
При использовании в роли /append (путем добавления образа тома к существующему файлу WIM) /export не позволяет изменять атрибут /compression WIM-файла.
При экспорте полностью нового образа тома Windows PE 2.0 можно указать ключ /boot.

Ключ /export был создан в качестве ответа на ранее упоминавшиеся ситуации и на ряд других, более экзотических ситуаций, обнаруженных разработчиками. По сути, /export позволяет взять существующий образ тома (или два, или три) и экспортировать его. Это означает быстрое взятие WIM-файла X и X1 из примера выше и либо создание нового WIM только с X, либо только с X1, или с X1 и Y1, путем экспорта из еще одного файла WIM.
Вообразите ситуацию, в которой пользователь вносит изменения в X и добавляет изменения через /append как X1. Затем он хочет удалить X, поскольку уже заменил его новым образом на этот квартал. Для этого можно использовать ключ /delete, и в таком случае ImageX забудет об образе X. Но чтобы освободить пространство, устранив всю информацию, относящуюся к X, надо запустить следующую команду:
ImageX /export source.wim 2 destination.wim "New image for Q4CY07"
В результате второй образ тома экспортируется как новый файл WIM с новым именем, что полностью устраняет всю более раннюю информацию из образа тома 1. Возможен также экспорт из составных образов WIM, если заново собрать их как один WIM-файл (об этом будет сказано ниже). Составные образы нельзя править с помощью /mountrw – одна из причин, по которой их стоит собирать заново. Важно отметить, что в ImageX нет команды /import, поскольку с помощью /export можно как создавать новые WIM-файлы, так и дополнять существующие. Дополнительные сведения приведены на боковой панели «Важные замечания насчет /export».
Это также очень важно при использовании peimg /prep: хотя эта команда подготавливает образ Windows PE к использованию, она не вычищает ничего в WIM-файле. В идеале, пользователю следует подготовить образ и экспортировать его в новый файл boot.wim в качестве части процесса выпуска Windows PE. Отметьте, что процесс загрузки ищет WIM-файл только в \sources\boot.wim, так что удостоверьтесь, что он правильно назван и помечен как загрузочный образ тома.
Я уже упоминал, что пользователь, вероятно, пожелает оптимизировать свои образы, запуская /export для них, когда собирается избавиться от старых образов томов или слить вместе несколько из них. Это также разумно в случае, если были сделаны многочисленные правки через /mountrw или /delete. В ином случае, WIM-файл будет продолжать расти со временем (загадочным образом, который нельзя обнаружить). При регулярном использовании /mountrw или /delete подумайте о добавлении /export в рабочий процесс, чтобы гарантировать оптимизацию образов.

Составные образы
Другой проблемой, всплывшей на раннем этапе, была вероятная необходимость для WIM-файлов размещаться на нескольких блестящих носителях. Мы предвидели, что Windows будет поставляться более чем на одном компакт-диске (и, потенциально, диске DVD, как и случилось) и, как следствие, встроили поддержку составных образов в WIM и ImageX.
Как я уже упоминал, составные образы, созданные при помощи /split, по сути предназначены только для чтения – для нового составного образа нельзя использовать /capture, его нельзя устанавливать при помощи ImageX и его нельзя добавить к чему-то посредством /append. Как результат, я рекомендовал бы делить WIM-файлы только после завершения стандартного рабочего процесса и достижения готовности к выпуску, то есть выполнять все правки на нормальном файле WIM и думать над разделением как частью процесса выпуска для сценария развертывания.
Когда дело доходит до применения образа, составные образы могут быть проблемными. Я бы рекомендовал использовать ImageX вместо обычной установки при работе с составными образами. Я бы также рекомендовал либо применять образы через сеть (для оптимизации производительности без создания образа диска, с которого идет применение), либо копировать их прямо на жесткий диск и затем применять (отметив, что это привяжет к диску, поскольку диск ведет чтение и запись на себя во время применения).

В поисках способа проверки
При использовании ImageX перемещается много данных – много очень важных данных. В этом коду на Tech•Ed я часто слышал вопрос, «Как я могу гарантировать верность своих образов?» Ну, не то чтобы эта задача была совсем легкой, но и очень сложной ее назвать нельзя.
В первую очередь следует понять, что WIM, как и большинство архивных форматов, подвержен порче данных. Чаще всего повреждения и сбои возникают при передаче WIM-файла по сети. Уже в начале разработки Windows Vista мы видели конкретные проблемы с конкретными сетевыми картами – если они теряли пакеты, WIM-файл оказывался поврежденным, и не всегда это было легко определить. Эта ситуация была отражением той, что случилась годы назад, когда файл driver.cab вырос в размере – начали происходить подобные же случайные повреждения. Как правило, при получении сообщений о поврежденных образах или сбое установки стоит проверить, какие типы сетевых адаптеров используются на системах, выдающих сообщения. Это имеет место как при использовании ImageX самого по себе, так и при работе с WDS.
Как можно увидеть, цел образ или нет? Во-первых, можно использовать ключ /check. Он позволяет избавиться от лишних проверок целостности WIM-файл и проверить до применения, что данный WIM не был поврежден. Не забудьте запустить /check также и во время применения, что подтвердит целостность образа (хотя и займет больше времени).
Вдобавок, если возникли проблемы, или просто для гарантии, можно пропустить файлы через служебную программу контрольного суммирования перед записью образа и после применения. Можно провести проверку и после записи, подключив образ и проведя пересчет контрольной суммы – неплохой способ удостовериться, что образ был создан верно.
Желательно удостоверяться, что образы записываются верно, с самого начала. Ключ /check и сам формат созданы как контрольные точки, а не как средства восстановления для починки неверно записанных образов.

Загрузка и флаги
Я уже упоминал, что для записи образа тома WIM в Windows PE и его загрузки можно использовать ключ /boot. Можно представить это просто как загрузочный сектор на конкретном образе тома. В одном WIM-файле может существовать один образ тома, и верно это лишь для Windows PE 2.0. Обратите внимание, что загрузка с WIM в Windows PE 1.x просто невозможна.
В образах тома Windows можно заметить ссылки на флаги. Флаги используются только программой установки Windows. Флаг 2 на образе тома значит, что этот образ тома содержит Windows PE и программу установки. Флаг 9 означает, что он содержит только Windows PE. Любой другой флаг (или отсутствие флага) означает, что образ не будет и не может быть использован программой установки. Следует заметить, что флаги можно установить на образ после его создания, используя ImageX для внесения изменений. Я рекомендую использовать WAIK (и, как вариант, пакет Business Desktop Deployment Solution Accelerator) для создания загрузочного образа Windows PE в формате WIM, так как при этом флаги будут правильно установлены с самого начала.

Примечание для пользователей HTA
Недавно мне пришлось слышать несколько сообщений о проблемах с запуском файлов HTA на Windows PE 2.0. Увы, похоже, существуют проблемы с HTA-файлами, содержащими любые существенные сценарии. На рис. 4 взгляните на снимок экрана с созданным мною примером файла и заметьте возвращенную ошибку сценария (без информации). Об этой проблеме сообщили несколько клиентов, и я столкнулся с ней сам.
Рис. 4 Ошибка со сценариями HTA
Рис. 4 Ошибка со сценариями HTA
К счастью, ее легко решить. При подготовке образа добавьте не только поддержку HTA, но и поддержку XML. То, чего не достает компоненту HTA, похоже, включено в модуль надстройки XML, что решает проблему.
Я хотел бы поблагодарить Брюса Грина (Bruce Green), разработчика ImageX, а также Минсяо Жу (Minxiao Zhou) и Раджа Ганджикунта (Raja Ganjikunta) из группы тестирования развертывания Windows за их помощь в создании этого выпуска.

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


 Заметки разъездного инженера: Повторное использование компьютера
Заметки разъездного инженера
Повторное использование компьютера
Джим Линч (Jim Lynch)

Программа Community MAR (Microsoft Authorized Refurbisher) (microsoft.com/mar) представляет собой выдающийся и сравнительно малоизвестный проект в рамках инициативы Майкрософт Unlimited Potential (мир безграничных возможностей), в которой корпорация поддерживает разнообразные проекты по улучшению обучения, созданию предприятий и рабочих мест и надежных экономических перспектив для многих обездоленных сообществ. Программа Community MAR возникла в Соединенном Королевстве в 2000 г. и в настоящее время объединяет в 50 странах более 800 предприятий, восстанавливающих ПК.
Одна из наиболее поразительных особенностей программы Community MAR заключается в том, что она может предоставлять лицензии для Windows® 2000 и Windows XP всего за 5 долларов США. Предприятия MAR предоставляют эти лицензии (более 200 000 в год) на восстановленных ПК некоммерческим организациям, школам, библиотекам и колледжам. В США лицам с низким уровнем дохода или инвалидам также предоставляются программы доступа к новым технологиям. Таким образом, предприятия, участвующие в программе Community MAR, приходят к тем, кто оказался на неудачливой стороне цифрового неравенства, и предоставляют им возможности для обучения и трудоустройства.
В поисках обездоленных детей предприятия Community MAR исследуют все уголки земного шара. Например, Operation Homelink поставляет компьютеры семьям военнослужащих США, имеющим низкие доходы; в Соединенном Королевстве организация Computer Aid International является крупнейшей неправительственной организацией, поставляющей компьютеры в Африку; а сеть канадских предприятий Computers for Schools, восстанавливающих компьютеры, поставляет значительную часть компьютеров, поступающих в канадские школы.
Важность повторного использования
Недавно Агентство по охране окружающей среды США в сотрудничестве с университетом Теннесси продемонстрировало важность повторного использования электроники, выраженную в терминах энергии, материалов, выделения CO2и токсических веществ. Согласно их средству Electronics Environmental Benefits Calculator (eerc.ra.utk.edu/ccpct/eebc/eebc.html), повторное использование только одного компьютера с монитором на ЭЛТ позволяет сэкономить:
  • 30 фунтов опасных отходов
  • 77 фунтов твердых отходов
  • 77 фунтов материалов
  • 147 фунтов (17,5 галлонов) воды спасти от загрязнения
  • 32 тонны воздуха спасти от загрязнения
  • предотвратить выброс в атмосферу 1333 фунтов CO2
  • 7719 киловатт энергии

Фактически программа Community MAR возникла в 2000 г. с целью увеличения потока работоспособного оборудования в школы и благотворительные организации Соединенного Королевства, которые традиционно имели ограниченный доступ к новым технологиям. Программа распространилась на США и Австралию в 2003 г. и стала всемирной в 2005 г. В настоящее время она доступна всем типам предприятий (коммерческим, некоммерческим, правительственным и базирующимся на школах), занимающихся восстановлением компьютерного оборудования. Попутно была создана активно действующая отрасль восстановления и повторного использования компьютеров.
Одним из менее очевидных достоинств программы Community MAR является положительное влияние на окружающую среду. Продление срока службы электронного оборудования является наиболее эффективной формой переработки отходов, поскольку при этом сохраняется высокое предназначение устройства и достигаются значительные экономические, социальные и экологические выгоды. Безусловно, переработка по окончании срока службы является разумной и необходимой процедурой, но при этом на каждом отдельном экземпляре теряется 10-30 процентов материалов и энергии.
Неудивительно, что производство компьютеров дорого обходится для окружающей среды. Согласно Эрику Д. Уильямсу (Eric D. Williams), ученому-экологу из университета штата Аризона, для производства среднего 53-фунтового настольного компьютера и монитора требуется 530 фунтов ископаемых энергоносителей, 50 фунтов химических веществ и 3330 фунтов воды. Продление срока службы компьютера на два или три года экономит за время службы компьютера в 5 - 20 раз больше энергии, чем его переработка по окончании срока службы (еще более поразительные цифры приведены на боковой панели «Важность повторного использования»).
В целом, посредством этой инновационной программы Майкрософт помогает создавать возможности, изменяющие сообщества благодаря предоставлению технологических преимуществ нуждающимся людям. Программа Community MAR удивительным образом повысила осведомленность общественности о повторном использовании компьютеров и увеличила поддержку этой тенденции — это еще одно достоинство программы.

Джим Линч (Jim Lynch) является руководителем программы переработки и повторного использования компьютеров, размещенной по адресу TechSoup.org на веб-узле некоммерческой организации, базирующейся в Сан-Франциско. Ее задачей является поставка для благотворительных организаций по всему миру дешевого оборудования, программного обеспечения и технологий.


 Конфиденциальные сведения о Windows: Вызывая доктора Ватсона
Конфиденциальные сведения о Windows
Вызывая доктора Ватсона
Рэймонд Чен (Raymond Chen)

Вы могли заметить, что если запросить программу Dr. Watson (drwtsn32.exe) получить дамп памяти процесса Winlogon, то Windows® выключается, как только эта операция выполнится. Некоторые могли бы поинтересоваться: «почему присоединение отладчика к процессу Winlogon обрушивает всю систему?»
Дело в том, что запуск доктора Ватсона на некоторый процесс это совсем не то же самое, что присоединение к этому процессу отладчика. Присоединение отладчика включает использование чего-то вроде ntsd, и при наличии нужных полномочий это нормально работает. Фактически именно так команда разработчиков Windows отлаживает Winlogon. Таким образом, формально можно ответить, что «присоединение отладчика к Winlogon не разрушает систему».
Однако доктор Ватсон — не врач, а патологоанатом. Сначала он должен получить дамп памяти процесса с ошибкой, а потом завершить этот процесс. Поскольку служебная программа «Доктор Ватсон» не устраняет ошибки, то если процесс продолжит работу, сбой произойдет снова. В результате опять будет вызван доктор, что замкнет бесконечный цикл. В этом смысле доктор Ватсон – это отладчик, который ничего не отлаживает. Добрый доктор просто появляется на сцене, делает нужные записи, а затем уничтожает процесс. Так и происходит: после снятия дампа памяти процесс Winlogon завершается, что приводит к краху системы.
Если завершить процесс Winlogon, система перезагрузится.
Если завершить процесс Winlogon, система перезагрузится.
Winlogon является тем, что называется «критическим системным процессом», и прекращение работы критического процесса приводит к перезапуску системы. Почему же Winlogon считается критичным для работы системы? Прежде всего, Winlogon обрабатывает специальное сочетание клавиш — Ctrl+Alt+Del. Если Winlogon завершится, специальное сочетание клавиш перестанет работать. Это плохо само по себе, но еще хуже то, что в отсутствие системного обработчика специального сочетания клавиш, другая программа может дождаться, пока пользователь нажмет Ctrl+Alt+Del и показать в ответ поддельный диалог ввода пароля. Не очень хорошо то специальное сочетание клавиш, реакцию на которое можно подделать. В качестве меры защиты Windows завершает свою работу, чтобы не ухудшить уже достаточно плохую ситуацию.
Если вы теперь запустите диспетчер задач, выделите критический системный процесс вроде Winlogon, выберите «Завершить процесс» и подтвердите свое решение, то вот, елки-палки, вы только что завершили Winlogon, и система перезагрузится (если, конечно, вы работаете под учетной записью администратора и имеете достаточно прав, чтобы завершить этот процесс).
В предыдущих версиях Windows диспетчер задач пытался предотвратить завершение критического процесса, но алгоритм определения критических процессов был не очень умным. Кроме того, это позволяло подменить диспетчер задач и создать программу, которую, казалось бы, нельзя завершить. Конечно, на самом деле программу завершить было бы можно, нужно было просто воспользоваться другим средством, отличным от диспетчера задач. (Например, можно было бы попробовать программу taskkill).
Чтобы не быть подделанным, диспетчер задач больше не пытается предотвратить завершение критических системных процессов. В конце концов, чтобы не сделать что-то неправильно, лучше вообще этого не делать. Так что диспетчер задач больше не стоит у вас за спиной, когда вы завершаете процессы. И не бьет вас по рукам, когда вы пытаетесь завершить что-то, что лучше бы не трогать. Если вы решили остановить критический системный процесс, вам придется принять последствия этого.

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