Забавный казус произошёл с антивирусной программой Avira после очередного обновления антивирусных баз. Avira признал сам себя трояном, то есть шпионской программой. Точнее, к зловредным компонентам был отнесён файл AESCRIPT.dll, являющийся частью необходимых для функционирования программы ресурсом. Вредоносный файл получил идентификационный номер TR/Spy.463227.
Сейчас, если посмотреть в базе вирусных угроз на официальном сайте Avira, то по данному номеру можно увидеть следующую надпись:
«This is a known false alarm which was fixed with VDF version 7.11.16.146 Please run an update of your Avira product.»
В ней говорится о том, что ошибочное срабатывание антивируса было исправлено в новой версии антивирусных баз, и пользователю необходимо запустить обновление Avira для установки обновления за номером 7.11.16.146.
Ошибка была диагностирована и исправлена в тот же день, когда и проявилась на компьютерах пользователей – 26 октября.
30 сентября тоже из-за ошибки в очередном обновлении антивирусных баз в неудобную ситуацию попала компания Microsoft. Тогда фирменные антивирус компании Microsoft Security Essentials и Forefront Client Security, работающие на одном движке, за вредоносную программу признали веб-браузер Google Chrome. Они увидели в браузере троян PWS:Win32/Zbot, ворующий пароли. Microsoft также оперативно выпустил исправляющее ошибку обновление и извинилась перед пользователями.
В прошлом месяце я рассмотрел некоторые наиболее популярные сложности с отказоустойчивыми кластерами в Windows Server 2008 R2 и рассказал о способах корректного устранения этих неполадок.
Вспомните, что текущая политика поддержки предполагает, что решение отказоустойчивой кластеризации в Windows Server 2008 и Windows Server 2008 R2 может считаться официально поддерживаемым службой поддержки потребителей Microsoft (Customer Support Services, CSS), только если удовлетворяет следующим критериям:
Все компоненты, включая оборудование и программное обеспечение, должны удовлетворять требованиям для получения логотипа "Certified for Windows Server 2008 R2".Окончательно настроенное решение должно пройти проверочный тест в оснастке "Failover Cluster Management" (Управление отказоустойчивыми кластерами).
Есть несколько сценариев устранения неполадок. Они представляют самые популярные неполадки отказоустойчивых кластеров Windows Server 2008 R2 и шаги по их устранению.
Сценарий 1. В процессе ежемесячной очистки объектов Active Directory по неосторожности был удален Cluster Name Object. Вновь созданный объект не переходит в интерактивный режим.
Объект CNO (Cluster Name Object) это общий идентификатор кластера, и поэтому он очень важен. Он создается автоматически мастером создания кластера (Create cluster) и носит то же имя, что и кластер. По мере настройки новых служб и приложений в этой учетной записи, CNO создает другие виртуальные объекты. При удалении CNO или его разрешений он не может создавать другие необходимые кластеру объекты до тех пор, пока не будет восстановлен или ему не будут назначены соответствующие разрешения.
Как и в случае с другими объектами Active Directory, у CNO есть связанный идентификатор objectGUID. По нему отказоустойчивый кластер узнает, что имеет дело с правильным объектом. Если просто создать новый объект, то у него будет новый objectGUID. Нужно восстановить правильный объект, чтобы отказоустойчивый кластер мог продолжить нормальную работу.
При устранении этой неполадки нужно найти две вещи, относящиеся к ресурсу кластера. В Windows PowerShell выполните команду:
Get-ClusterResource "Cluster Name" | Get-ClusterParameterCreatingDC,objectGUID
Эта команда сообщает необходимые значения. Первый параметр — CreatingDC. Когда отказоустойчивый кластер создает CNO, отмечается контроллер домена, в котором он был создан. При любой выполняемой с кластером операции (создание виртуального объекта, перевод в интерактивное состояние и т.п.) к этому контроллеру обращаются за объектом CNO и информацией безопасности. Если контроллер домена найти не удается или он недоступен, тогда уже выполняется поиск любого другого ответственного контроллера.
Второй параметр – objectGUID – отвечает за то, чтобы можно было быть уверенным, что получен правильный объект. В нашем случае имя кластера —CLUSTER1, контроллер, на котором он был создан, — DC1, а значение objectGUID — 1a3cf049cf79614ebd94670560da6f04:
Object Name Value
—— —- —–
Cluster Name CreatingDC \\DC1.domain.com
Cluster Name ObjectGUID1a3cf049cf79614ebd94670560da6f04
Надо войти в систему DC1 и открыть консоль Active Directory Users and Computers (Active Directory — пользователи и компьютеры). Если в ней есть текущий объект CLUSTER1, можно проверить наличие в нем правильных атрибутов. Редактор атрибутов Active Directory не показывает GUID, поскольку он не отражается в шестнадцатеричном формате.
В противном случае мы увидели бы такое значение 49f03c1a-79cf-4e61-bd94-670560da6f04. Шестнадцатеричный формат преобразуется и работает в парах, что немного смущает. Если взять первые восемь пар и выполнить преобразование, то 49f03c1a станет 1a3cf049. В следующих двух парах 79cf станет cf79, а 4e61 — 614e. Оставшиеся пары останутся такими же.
Чтобы увидеть в шестнадцатеричном формате то, что видит отказоустойчивый кластер, свойства объекта objectGUID нужно передать в редактор атрибутов. Поскольку это неправильный объект, сначала надо удалить объект, чтобы было возможно восстановить правильный объект.
Восстановить объект можно несколькими способами. Можно воспользоваться Active Directory Restore, утилитой, подобной ADRESTORE, или новой корзиной Active Directory (если это контроллер домена Windows 2008 R2 с обновленной схемой). Новая корзина значительно упрощает процесс и делает его самым удобным для восстановления объектов Active Directory.
С помощью корзины Active Directory можно найти объект восстановления, выполнив команду Windows PowerShell:
Get-ADObject –filter 'isdeleted –eq $true –and samAccountName –eq "CLUSTER1$"' –includeDelectedObjects –property * | FormatListsamAccountName,objectGUID
Эта команда выполняет поиск всех удаленных объектов с именем CLUSTER1 в корзине Active Directory. В результате получаем имя учетной записи и objectGUID. Если найдены несколько элементов, все они будут показаны. При просмотре нужного элемента мы увидим:
samAccountName : CLUSTER1$objectGUID:49f03c1a-79cf-4e61-bd94-670560da6f04
Теперь его надо восстановить. После удаления неправильного объекта для восстановления следует использовать такую команду Windows PowerShell:
Restore-ADObject –identity 49f03c1a-79cf-4e61-bd94-670560da6f04
В результате объект будет восстановлен в том же месте (подразделении) с теми же разрешениями и паролем, известным Active Directory.
Это одно из преимуществ корзины Active Directory по сравнению с аналогами утилиты ADRESTORE. При восстановлении эти утилиты сбрасывают пароль, перемещают объект в соответствующий контейнер, восстанавливают объект в отказоустойчивом кластере и т.д.
Используя корзину, мы просто переводим ресурс в интерактивный режим. Это более удачный вариант, чем восстановление Active Directory, особенно если позже были созданы новые объекты пользователя или компьютера, удалены старые объекты и т. п.
Сценарий 2. В оснастке «Управление отказоустойчивым кластером» общие тома кластера отмечены как Redirected Access (перенаправленный доступ). Как исправить ситуацию?
Во-первых, уточним определение общих томов кластера. Они упрощают настройку и управление виртуальными машинами Hyper-V в отказоустойчивых кластерах. Благодаря наличию общих томов в отказоустойчивом кластере, работающие под управлением Hyper-V, множество виртуальных машин могут использовать один LUN и при этом перемещаться между узлами независимо друг от друга. Общий том кластера обеспечивает повышение гибкости томов в кластерном хранилище. Например, для оптимизации дисковой производительности можно хранить системные файлы отдельно от данных, даже если системные файлы и данные размещены в файлах виртуального жесткого диска.
Надо позаботиться, чтобы в параметрах всех сетевых адаптеров, обеспечивающих связь кластеров, были установлены компоненты Client for Microsoft Networks (Клиент для сетей Microsoft) и File and Printer Sharing for Microsoft Networks (Общий доступ к файлам и принтерам в сетях Microsoft), для поддержки протокола SMB (Server Message Block). Это необходимо для общего тома. Сервер работает под управлением Windows Server 2008 R2, что автоматически обеспечивает версию SMB, необходимую для общего тома, а именно SMB2.Используется только одна предпочтительная коммуникационная сеть для общего тома, но включение этих параметров во множестве сетей поможет кластеру противостоять отказам.
Перенаправление доступа подразумевает, что все операции ввода-вывода «перенаправляются» по сети на другой узел, имеющий доступ к диску. Могут быть три причины для перехода в режим перенаправления доступа:
Режим настроен вручную.Идет процесс резервного копирования.Имеются неполадки с оборудованием, и узел не может напрямую получить доступ к диску.
В нашем сценарии мы исключили первые два варианта. Остается третий. Если заглянуть в журнал системных событий System Event Log, можно увидеть событие отказоустойчивой кластеризации "Event ID: 5121".
Определение этой записи журнала: Общий том кластера CSV «Cluster Disk x» более не доступен напрямую с этого узла кластера. Ввод-вывод будет перенаправлен на устройство хранения по сети через узел-владелец, которому принадлежит этот том. Это может привести к снижению производительности. Если перенаправление доступа к этому тому включено, отключите его. Если перенаправление доступа отключено, устраните неполадки связи этого узла с устройством хранения; после восстановления связи с устройством хранения работоспособность ввода-вывода будет также восстановлена.
В такой ситуации надо тщательно изучить все предшествующие этому события, связанные с оборудованием. Это значит, что надо искать такие события, как 9, 11, 15, которые указывают на неполадки оборудования или связи. Стоит провести физическую проверку диску в панели Disk Management (Управление диском). В большинстве случаев так удается обнаружить другие ошибки. Решив проблему, можно вывести диск из этого режима.
Следует помнить, что общий том остается включенным на протяжении всего времени, пока есть хотя бы один узел, подключенный с сети хранения. Именно поэтому будет установлен режим перенаправления. Все операции записи на диск отправляются в узел, который поддерживает связь, и виртуальные машины Hyper-V будут продолжать работу. Это может повлиять на их производительность, но они останутся работоспособными. В результате производственные серверы никогда не отключаются, а это уже хорошо.
Сценарий 3. Я только что создал новый отказоустойчивый кластер Windows 2008 R2 для виртуальных машин с высоким уровнем доступности. Диски настроены для работы с общим томом, но при попытке доступа к ним с помощью проводника или панели «Управление диском» происходит зависание. Я не могу скопировать на том файлы виртуального диска.
Существует только один «истинный» владелец диска и он называется узел-координатор (Coordinator Node). Запись любого типа метаданных выполняется только этим узлом.
Проводник или панель управления диском открывает диск с возможностью записи любых метаданных (если такое предполагается). По этой причине любой диск, не находящийся в собственности, перенаправляется по сети на узел-координатор. Это не совсем то же, что «перенаправление доступа».
В процессе устранения этой неполадки в оснастке «Управление отказоустойчивым кластером» можно увидеть, что диск находится в интерактивном режиме. Поэтому сначала надо изучить события в журнале. В журнале системных событий можно увидеть события отказоустойчивой кластеризации:
Событие ID: 5120
Общий том кластера «Cluster Disk x» больше не доступен на этом узле из-за «STATUS_BAD_NETWORK_PATH(c00000be)». Все операции ввода-вывода будут временно поставлены в очередь, пока путь к тому не будет восстановлен. (Cluster Shared Volume ‘Cluster Disk x’ is no longer available on this node because of ‘STATUS_BAD_NETWORK_PATH(c00000be).’ All I/O will temporarily be queued until a path to the volume is reestablished.)
Событие ID: 5142
С данного узла кластера больше нельзя получить доступ к общему тому кластера 'Cluster Disk x' из-за ошибки 'ERROR_TIMEOUT(1460)'. Проверьте подключение данного узла к устройству хранения и сети.
Эти события говорят о попытках подключения к узлу-координатору, которые завершаются таймаутом. Поэтому загляните в журнал системных событий и проверьте, нет ли там других ошибок, указывающих на связь узлов по сети. При наличии таковых необходимо устранить их. Ошибки могут быть вызваны поломкой или отключением сетевой карты.
Далее надо проверить возможность связь узлов по сети. Первым делом нужно проверить сеть, по которой передается трафик общего тома. В отказоустойчивом кластере сеть для общего тома выбирается, исходя из максимального значения метрики. Это отличается от того, как Windows идентифицирует сети.
Сетевой отказоустойчивый адаптер для отказоустойчивого кластера (Failover Cluster Network Fault Tolerance, NETFT) имеет свою собственную внутреннюю систему метрик. Все выявленные им сети имеют шлюз по умолчанию и получают метрики 10000, 10100 и т. д. Метрики всех сетей без шлюза по умолчанию начинаются с 1000, 1100 и т. д. Чтобы узнать, как адаптер NETFT определил их, можно использовать команду Windows PowerShell:
Get-ClusterNetwork | FT Name, Metric, Role
Вы увидите примерно следующее:
Name Metric
——————-
Management 10100
CSV Traffic 1000
LAN-WAN 10000
Private 1100
Среди этих сетей сеть, которую я определил как сеть общего тома, — CSV Traffic. Для узла Node1 я использовал IP-адрес 1.1.1.1 и 1.1.1.2 для узла Node2, поэтому я проверяю сетевое соединение с помощью команды PING.
Следующим шагом будет попытка соединения по протоколу SMB к указанным IP-адресам. Это то, что делает служба кластеризации. Чтобы получить ответ, достаточно выполнить простую команду:
NET VIEW \\1.1.1.1
В ответ будет получен или список общих ресурсов или сообщение "There are no entries in the list" (то есть список пуст).
Это указывает на то, что можно было бы создать соединение с этим общим ресурсом. Однако сообщение "System error 53 has occurred. The network path was not found" (Ошибка 53. Сетевой путь не найден) указывает на проблему в настройке TCP/IP сетевой карты.
Для работы с общим томом необходимы компоненты "Client for Microsoft Networks" и "File and Printer Sharing for Microsoft Networks". Если они отсутствуют, то возникает проблема с зависанием Проводника.
В Windows 2003 Server Cluster и ниже рекомендовалось отключать эти компоненты. Сейчас в этом нет необходимости.
Другие факторы
Есть несколько факторов, которые следует принять во внимание. Если узлы кластера вызывают отказ подсистемы размещения ресурсов (Resource Host Subsystem, RHS), первым делом нужно вспомнить о природе RHS и ее функциях. RHS — это компонент отказоустойчивого кластера, выполняющий проверку работоспособности множества ресурсов для обеспечения работоспособности. Что касается IP-адресов, то этот компонент проверяет, находится ли адрес в сетевом стеке и реагирует ли на запросы. Проверяя диски, он пытается соединиться и выполнить команду DIR.
Если сбоит RHS, проверьте журнал системных событий на наличие записей с идентификаторами 1230 и 1146. В событии 1230 фактически указывается ресурс и используемые библиотеки DLL. Если произошел сбой, это означает, что ресурс не отвечает должным образом и возможна взаимная блокировка. Если сбой произошел на дисковом ресурсе, следует просмотреть наличие ошибок, связанных с диском или слишком большим временем отклика диска. Неплохо начать с использования монитора производительности (Performance Monitor). Также приветствуется обновление драйверов и микропрограммы карт или компонентов сети.
Помимо этого следует сделать некоторые наблюдения. Служба кластеризации проводит проверку работоспособности пользовательских процессов из режима ядра, чтобы выявить, когда пользовательский режим перестает отвечать или происходит зависание. Для вывода из этого состояния служба кластеризации проводит проверку ошибкой. Если это происходит, будет получена ошибка Stop 0×0000009E. Чтобы устранить неполадку, надо изучить файл дампа, созданный для поиска причин зависания. Также можно запустить монитор производительности и посмотреть, будут ли возникать зависания, утечки памяти и т. п.
Служба кластеризации зависит от инструментария управления Windows (Windows Management Instrumentation, WMI). Если возникают проблемы с WMI, это ведет к проблемам с кластеризацией (с созданием и добавлением узлов, миграцией и т. п.). Проверьте WMI, например, WBEMTEST.EXE или даже удаленные сценарии WMI.
Один сценарий можно попытаться выполнить в консоли Windows PowerShell (здесь NODE1 — имя узла):
get-wmiobjectmscluster_resourcegroup -computer NODE1 -namespace "ROOT\MSCluster"
Он создает соединение WMI с кластером и предоставляет информацию о группах.
Неудачное завершение сценария указывает на проблемы с WMI. Перезапустите службу WMI, если она остановлена. Может быть повреждена база данных WMI (для проверки целостности воспользуйтесь командой Windows PowerShell: winmgmt /salvagerepository) и т. д.
Помните о ряде правил устранения неполадок:
Проверяйте, проверяйте и еще раз проверяйте. При устранении неполадок используйте тесты для проверки кластера. Используйте их при изменении системы.Все больше систем переводятся на Windows PowerShell, поэтому начните изучать эту технологию, если вы ее еще не освоили.Если вы зависите от объектов Active Directory, защитите их. Разрешите использование корзины Active Directory и защитите объекты от случайного удаления.При устранении неполадок общего тома не забывайте, что проблема может быть не только в неполадках оборудования.При устранении неполадки сделайте шаг назад и внимательно проанализируйте все, на что она может оказывать влияние, и постепенно сужайте поле поиска.
Служба отказоустойчивой кластеризации создана для выявления, восстановления и предоставления отчетов об ошибках. Когда кластер «говорит», что есть или была неполадка, это не значит, что он вызвал ее. Как говорится, "не убивайте гонца, принесшего дурную весть".
Технология развертывания настольных систем с годами сильно изменилась. С первых дней существования Windows 2000 и Windows XP для обеспечения правильного развертывания необходимо было следовать довольно жестким действиям и выполнять настройку вручную. Затем необходимо было подключить образ, используя инструменты сторонних производителей. Сегодня это полностью гибкий процесс, в который было внесено множество улучшений.
Корпорация Майкрософт представила пакеты инструментов развертывания вместе с Windows Vista, и они были значительно улучшены в Windows 7. Эти инструменты предоставляют инфраструктуру для создания образов настольных систем, которые можно настраивать, обновлять, автоматизировать и выполнять развертывание любыми способами в соответствие с потребностями организации. Процесса, выполняемого вручную и бессистемно, больше нет. Теперь можно использовать инструменты, обеспечивающие значительную гибкость и эффективность.
Эти новые инструменты и методы развертывания упрощают и ускоряют процесс развертывания настольных систем. Можно создавать, обновлять и управлять образами Windows 7; сохранять и переносить данные пользователей; устранять проблемы совместимости приложений; и предоставлять более крупную инфраструктуру для объединения всего этого.
Пакет автоматической установки Windows
Начнем с основных стандартных блоков развертывания. Большинство из них входят в состав пакета автоматической установки Windows или Windows AIK. Инструменты, включенные в Windows AIK, обеспечивают большинство функций, необходимых для создания, настройки и развертывания образов Windows (см. рис. 1).
ИнструментОписаниеДиспетчер образов систем WindowsОткрытие образов Windows, создание файлов ответов и управление дистрибутивными общими ресурсами и наборами конфигураций.ImageXЗапись, создание, изменение и применение образов Windows.Средства управления развертыванием образа и обслуживания (DISM)Установка обновлений, драйверов и языковых пакетов для образов Windows. Средства DISM доступны во всех установках Windows 7 и Windows Server 2008 R2.Среда предустановки Windows (Windows PE)Минимальная среда ОС, используемая для развертывания Windows. Windows AIK включает в себя несколько инструментов для создания и настройки сред Windows PE.Средство миграции пользовательской среды (USMT)Перенос данных пользователя из предыдущих ОС Windows в Windows 7.
Рис. 1. Инструменты и служебные программы, входящие в состав Windows AIK.
Если ранее вы использовали некоторые инструменты пакета Windows AIK для Windows Vista, вы заметите, что в Windows AIK для Windows 7 появилось средство USMT 4.0. В состав USMT входит ряд новых функций, включая хранилище миграции жестких ссылок, автономное сохранение данных пользовательской среды и, что самое важное, тесную интеграцию с System Center Configuration Manager и набор средств развертывания Microsoft Deployment Toolkit (MDT). Дополнительные сведения о новых возможностях USMT см. в заметках о выпуске USMT 4.0.
Пакет Windows AIK требуется для большинства описанных в данной статье методов развертывания. Загрузите Windows AIK для Windows 7 здесь.
Виртуализация и совместимость приложений
Одна из самых распространенных проблем, которая может встретиться при выполнении развертывания настольных систем — это совместимость приложений, особенно устаревших приложений (которые могут больше не поддерживаться). Они по-прежнему могут быть критически важны для бизнеса, поэтому их потребуется определить и разместить. Перед тем, как приступить к действительному развертыванию, набор средств для обеспечения совместимости приложений (ACT) поможет устранить возможные проблемы совместимости приложений.
ACT помогает рационализировать существующие приложения благодаря определению возможного дублирования, конфликтующих версий и т.д. Помогая стандартизировать набор приложений в организации вы можете уменьшить число приложений, которые следует протестировать до развертывания.
По завершении процесса рационализации ACT поможет выполнить тестирование каждого приложения на совместимость с Windows 7. Это может быть простым представлением сведений, данных разработчиком приложения с указаниями о совместимости приложения. Однако в некоторых случаях вы столкнетесь с собственными приложениями, для которых требуется более тщательное тестирование. Вы также можете встретиться с известными несовместимым приложениями, для правильной работы которых в Windows 7 требуется перенос.
Для некоторых приложений можно применить исправления совместимости, также называемые оболочками, для обеспечения их правильной работы в Windows 7. Оболочки также можно использовать с большим числом ранее несовместимых приложений, чтобы быстро и просто заставить их работать. Например, оболочки совместимости позволяют запускать приложения якобы с правами администратора или якобы в Windows XP, хотя в действительности приложение выполняется в Windows 7.
Для приложений, проблему несовместимости которых нельзя устранить с помощью оболочек совместимости и ACT, может потребоваться использовать технологию виртуализации для запуска приложений в режиме Windows XP. Также можно использовать Microsoft Enterprise Desktop Virtualization (MED-V) для эмуляции предыдущих версий Windows.
MED-V входит в состав пакета оптимизации рабочей среды Майкрософт (MDOP). Она позволяет запускать приложения на виртуальной машине под управлением более старых ОС совершенно прозрачно и безболезненно для пользователей. Приложения работают так, как если бы они были установлены на настольной системе. Пользователи могут даже прикреплять их к панели задач.
Набор средств развертывания Microsoft (MDT)
После установки Windows AIK и использования ACT для подготовки приложений к переносу в Windows 7 необходимо приступить к созданию и развертыванию образов Windows 7. MDT — основа процесса развертывания настольных систем. Этот набор средств развертывания предоставляет исчерпывающую платформу для настройки, автоматизации и развертывания новых настольных систем Windows 7. Он также поддерживает развертывание Windows Server 2008 R2, Windows Server 2008 и Windows Server 2003.
Последняя версия, MDT 2010 Update 1, предлагает ряд улучшений. Теперь она поддерживает Office 2010, позволяя пользователям инициировать и настраивать собственные развертывания с помощью Configuration Manager и имеет улучшенную поддержку драйвера Windows 7.
Благодаря централизованной панели управления под названием Deployment Workbench (см. рис. 2) MDT полностью автоматизирует процесс развертывания новой ОС. MDT поддерживает три основные сценария развертывания. Установка с незначительным участием пользователей (LTI), установка без участия пользователя (ZTI) и установка с участием пользователей (UDI). Каждый сценарий обеспечивает различные уровни автоматизации и взаимодействия с пользователем на основе потребностей и возможностей. Более подробно о выборе наилучшего сценария для вашей ситуации можно в документе «Использование набора Microsoft Deployment Toolkit», который включен в загрузку MDT.
Рис. 2. Средство Deployment Workbench в MDT 2010 Update 1.
Также существует ряд подходов к созданию образов. Можно создать «толстый» образ, содержащий всю настольную среду, включая ОС, драйверы, приложения и т.д.
И наоборот, «тонкие» образы представляют минималистский подход и содержат только самое необходимое для создания настольной вычислительной среды. Этот подход позволяет добавлять приложения и параметры позднее.
Наконец, название «гибридный образ» говорит само за себя: это «компромиссный» образ, включающий в себя основные приложения и настройки, относящиеся ко всем пользователям. Позднее можно применить дополнительные настройки.
После выбора способа развертывания и типа образа необходимо использовать MDT для создания общего ресурса развертывания (см. рис. 3). В нем будут храниться образы, и из него будет выполняться их развертывание.
Рис. 3. Создание нового общего ресурса развертывания.
В новый общий ресурс развертывания можно добавлять операционные системы (см. рис. 4), приложения, пакеты (включая системные обновления, исправления и т.д.) и драйверы.
Рис. 4. Добавление ОС к общему ресурсу развертывания.
После добавления всех компонентов необходимо создать последовательность задач. Эта последовательность контролирует все ключевые этапы выполнения основных сценариев развертывания. MDT включает ряд шаблонов последовательностей задач, помогающих приступить к работе, включая Standard Client deployment task sequence (см. рис. 5).
Рис. 5. Последовательность Standard Client deployment task sequence.
В шаблоне последовательности задач можно добавлять, удалять и настраивать все этапы развертывания в соответствие с собственными потребностям. На вкладке «OS Info» (Информация ОС) шаблона можно открыть Windows SIM, входящий в состав Windows AIK. Windows SIM (см. рис. 6) позволяет изменять атрибуты ОС, включая информацию о регистрации и активации, внешний вид, членство в домене и т.д.
Рис. 6. Изменение атрибутов образа Windows в Windows SIM.
Это далеко не все. Как упоминалось ранее, платформа MDT включает ряд сценариев развертывания, включая LTI, ZTI и UDI. Они используют различные технологии развертывания, включая Windows Deployment Services (WDS) и nd System Center Configuration Manager. В файлы справки MDT включена полная документация и пошаговые инструкции для этих сценариев.
Можно загрузить последний выпуск MDT вместе с полной документацией процессов и инструментов MDT. Также доступна готовая к печати документация. Кроме того, обязательно ознакомьтесь сблогом Майкла Нихауса (Michael Niehaus) и блогом Deployment Guys, в которых содержатся дополнительные советы, видео и пошаговые руководства по развертыванию Windows 7 вместе с MDT.
Как давнего программиста на Python меня заинтриговало интервью с Доном Сайми (Don Syme), архитектором языка F#. В этом интервью Дон упомянул, что «некоторые рассматривают [F#] как строго типизированную разновидность Python, вплоть до различий в синтаксисе». Это поразило меня, и я решил, что этот вопрос стоит изучить глубже.
Как оказалось, F# — совершенно новый и очень интересный язык программирования, который до сих пор остается загадкой для многих разработчиков. F# предлагает те же преимущества в эффективности труда программистов, что и Ruby/Python в последние годы. F# — подобно Ruby и Python — высокоуровневый язык с минимальным синтаксисом и элегантностью выражения. Но настоящая уникальность F# заключается в том, что он сочетает в себе эти практичные средства с изощренной системой логического распознавания типов (type-inference system) и многими достижениями из мира функционального программирования. Это размещает F# в классе с несколькими узлами.
Но новый высокопродуктивный язык программирования — не единственная на сегодня новая интересная технология.
Широкое распространение облачных платформ вроде Windows Azure делают доступными распределенные хранилища и компьютерные ресурсы как крупным компаниям, так и разработчикам-одиночкам. Наряду с облачными хранилищами появились полезные инструменты наподобие горизонтально масштабируемого алгоритма MapReduce, которые позволяют быстро писать код, способный эффективно анализировать и сортировать потенциально гигантские наборы данных.
Этот подход удобен для отладки на скорую руку F#-программ. Такие инструменты дают возможность, написав несколько строк кода и развернув их в облаке, манипулировать гигабайтами данных. Просто замечательно.
В этой статье я поделюсь с вами некоторыми из своих находок в области F#, Windows Azure и MapReduce. Я покажу, как можно использовать F# и алгоритм MapReduce для разбора файлов журналов в Windows Azure. Сначала мы рассмотрим некоторые методики создания прототипов (prototyping), чтобы уменьшить сложность программирования MapReduce, а затем перенесем результаты нашего труда в… облако.
Азы работы с F#
Один из новых стилей работы, ставших доступными .NET-программистам с появлением F#, — рабочий процесс Interactive, привычный многим программистам на Perl, Python и Ruby. При таком стиле программирования часто используют среду интерактивного кодирования вроде оболочки самого Python или отдельный инструмент, например IPython. Это позволяет разработчику импортировать класс из модуля, создать его экземпляр, а затем, используя командную строку, изучить его методы и данные.
Распространенный способ интерактивной разработки, который станет привычным .NET-программистам, — простое написание кода в Visual Studio и передача его фрагментов в окно F# Interactive для выполнения. Фрагменты отправляются нажатием комбинации клавиш Alt+Enter применительно к текущему выделенному тексту. Кроме того, нажатие Alt+' позволяет отправить в это окно единственную строку. Пример использования этой методики показан на рис. 1.
Рис. 1. Использование окна F# Interactive
Этот подход удобен для отладки на скорую руку F#-программ; кроме того, в разрабатываемом вами скрипте на F# доступны и IntelliSense, и выполнение из командной строки.
Второй подход — вы вновь пишете код в Visual Studio, но потом копируете разделы кода из Visual Studio и напрямую вставляете их в автономную F# Interactive Console (рис. 2). В этом случае вы должны добавлять в конец вставленного кода две точки с запятыми. Это позволяет интерактивно взаимодействовать с кодом и дополнительно использовать преимущества выполнения из командной строки. Возможно, вы перейдете на этот вариант, когда привыкнете программировать в более интерактивном стиле.
Рис. 2. F# Interactive Console
Вы также можете вести интерактивную разработку на F#, запуская свой код непосредственно из Windows PowerShell; иначе говоря, передавая скрипт в fsi.exe (исполняемый файл F# Interactive Console) Одно из преимуществ такого подхода в том, что это позволяет быстро создавать прототипы скриптов и передавать результаты на стандартный вывод. Кроме того, можно итеративно изменять код в «облегченном» текстовом редакторе, например в Notepad++. На рис. 3 показан пример вывода от скрипта MapReduce, запускаемого из Windows PowerShell; этот скрипт я буду часто использовать в данной статье.
Рис. 3. Выполнение скрипта на F# в Windows PowerShell
PS C:\Users\Administrator\Desktop> & 'C:\Program Files (x86)\FSharp-2.0.0.0\bin\fsi.exe' mapreduce.fsscript192.168.1.1, 11192.168.1.2, 9192.168.1.3, 8192.168.1.4, 7192.168.1.5, 6192.168.1.6, 5192.168.1.7, 5
Все эти разные способы написания кода помогают справляться со сложными алгоритмами, программированием для сетей и облака. Вы можете быстро писать черновые варианты скриптов и запускать их из командной строки, чтобы увидеть, дают ли они ожидаемые вами результаты. После этого вы сможете вернуться к созданию более крупных проектов в Visual Studio.
Теперь, когда вы знаете азы работы в F#, давайте углубимся в какой-нибудь реальный код.
Разбор журналов в стиле MapReduce
В дополнение к ранее упомянутым преимуществам интерактивного программирования код на F# является четким и эффективным. Пример на рис. 4 состоит менее чем из 50 строк кода, но содержит все важные части алгоритма MapReduce для вычисления десяти наиболее часто встречающихся IP-адресов в наборе файлов журналов.
Рис. 4.Алгоритм MapReduce для разбора файла журнала
open System.IOopen System.Collections.Generic// Map Phaselet inputFile = @”web.log”let mapLogFileIpAddr logFile = let fileReader logFile = seq { use fileReader = new StreamReader(File.OpenRead(logFile)) while not fileReader.EndOfStream do yield fileReader.ReadLine() } // Takes lines and extracts IP Address Out, // filter invalid lines out first let cutIp = let line = fileReader inputFile line |> Seq.filter (fun line -> not (line.StartsWith(”#”))) |> Seq.map (fun line -> line.Split [|' '|]) |> Seq.map (fun line -> line.[8],1) |> Seq.toArray cutIp// Reduce Phaselet ipMatches = mapLogFileIpAddr inputFilelet reduceFileIpAddr = Array.fold (fun (acc : Map<string, int>) ((ipAddr, num) : string * int) -> if Map.containsKey ipAddr acc then let ipFreq = acc.[ipAddr] Map.add ipAddr (ipFreq + num) acc else Map.add ipAddr 1 acc) Map.empty ipMatches// Display Top 10 Ip Addresseslet topIpAddressOutput reduceOutput = let sortedResults = reduceFileIpAddr |> Map.toSeq |> Seq.sortBy (fun (ip, ipFreq) -> -ipFreq) |> Seq.take 10 sortedResults |> Seq.iter(fun (ip, ipFreq) -> printfn “%s, %d” ip ipFreq);;reduceFileIpAddr |> topIpAddressOutput
Эту автономную версию, которая впоследствии станет сетевой, можно разбить на три фазы: сопоставление (map phase), сокращение (reduce phase) и отображение (display phase).
Первой фазой является сопоставление. Функция mapLogFileIpAddr принимает файл журнала как параметр. В этой функции определена другая функция, fileReader, в которой используется методика функционального программирования для отложенного получения строки текста из файла (впрочем, языки вроде C# и Python тоже позволяют делать это). Далее функция cutIp разбирает каждую строку ввода, отбрасывает строки комментариев и возвращает IP-адрес и целое число (1).
Это эффективная методика обработки данных. Выделите весь блок кода, отвечающего за сопоставление, и выполните его в окне F# Interactive вместе со строкой:
let ipMatches = mapLogFileIpAddr inputFile
Вы увидите следующий вывод:
val ipMatches : seq<string * int>
Заметьте, что на данный момент никаких операций не выполнялось и что файл журнала не считывался. Единственное, что было сделано, — оценено выражение. Благодаря этому выполнение откладывается до тех пор, пока в нем не появится реальная потребность, и данные не извлекаются в память только ради того, чтобы оценить выражение. Это эффективная методика обработки данных, и ее эффективность станет особенно заметной, когда вам понадобится разбор гигантских файлов журналов, размеры которых исчисляются гигабайтами или терабайтами.
Если вы хотите прочувствовать разницу, просто добавьте line в функцию cutIp, чтобы она выглядела так (Примечание. строка |> Seq.toArray для конструкции функции совсем необязательна; в нашем примере она специально используется для убыстрения работы функции, если бы ее не было, функция просто бы работала медленно, как, например, функция mapLogFileIpAddr.):
let cutIp = let line = fileReader inputFile line |> Seq.filter (fun line -> not (line.StartsWith(”#”))) |> Seq.map (fun line -> line.Split [|' '|]) |> Seq.map (fun line -> line.[8],1) |> Seq.toArraycutIp
Если вы отправите этот код интерпретатору F# и предоставите большой файл журнала, содержащий несколько гигабайт данных, то можете прогуляться и выпить чашечку кофе, так как ваш компьютер будет занят чтением всего файла и генерацией для него сопоставлений «ключ-значение» в памяти.
В следующей части конвейера данных я принимаю вывод от предыдущей и отправляю результаты в анонимную функцию, которая подсчитывает число вхождений IP-адресов в последовательности. Все значения добавляются в структуру данных Map через рекурсию. Этот стиль программирования может оказаться трудным в понимании для разработчиков — новичков в функциональном программировании, поэтому вы, возможно, захотите вставить выражения print внутрь анонимной функции, чтобы видеть, что именно она делает.
При императивном программировании вы могли бы добиться того же, обновляя изменяемый словарь, в котором каждый IP-адрес хранится как ключ, перебирая последовательность IP-адресов в цикле, а потом обновляя счетчик для каждого адреса.
Последняя фаза не имеет ничего общего с алгоритмом MapReduce, но полезна при изучении скриптов на этапе создания прототипов. Результаты фазы сопоставления передаются из структуры данных Map в Seq, сортируются, а затем выводятся 10 наиболее часто встречающихся. Заметьте, что при таком стиле конвейеризации данных результаты одной операции перетекают в другую безо всякого цикла for.
MapReduce и Windows Azure
Закончив проверку прототипа, пора заняться его переносом в среду, напоминающую производственную. В качестве примера я перенес программу из настольной системы в Windows Azure.
Для начала будет полезно посмотреть на примеры F#-кода для Windows Azure по ссылке code.msdn.microsoft.com/fsharpazure и установить шаблоны Windows Azure. Особенно интересен пример webcrawler, где рабочая роль F# использует хранилище двоичных объектов и очереди. Этот проект стоит тщательно изучить, если вас интересует более «продвинутое» применение F# в сочетании Windows Azure.
Я не стану детально рассматривать конфигурирование фермы MapReduce со множеством узлов. Вместо этого я представлю общий обзор. Вся специфика изложена в статье Джоша Твиста (Josh Twist) в журнале MSDNMagazine «Synchronizing Multiple Nodes in Windows Azure» (msdn.microsoft.com/magazine/gg309174).
Сконфигурировать ферму MapReduce в Windows Azure можно несколькими способами. Один из примеров использования рабочих ролей F#, которые равномерно распределяются между рабочими ролями сопоставления (Map Workers) и сокращения (Reduce Workers), показан на рис. 5. Сделать это очень легко: вы просто копируете и вставляете функцию сопоставления в Map Worker, а функцию сокращения — в Reduce Worker.
Рис. 5. Ферма MapReduce в Windows Azure
Детальное объяснение распределенного алгоритма и его возможных реализаций отлично представлено в презентации MapReduce, подготовленной Джеффом Дином (Jeff Dean) и Санжаем Гемаватом (Sanjay Ghemawat) (labs.google.com/papers/mapreduce-osdi04-slides/). Однако в примере на рис. 5 показано, что рабочие роли F# параллельно используют несколько файлов журналов. Потом они возвращают свой вывод, состоящий из ключей IP-адресов со значением 1, через Windows Azure AppFabric Service Bus рабочим ролям сокращения или с помощью записи на диск.
Далее рабочие роли сокращения считывают эти промежуточные данные и выдают суммарный счетчик пар «ключ-значение», записывая их в хранилище двоичных объектов. Каждая такая роль создает собственный отчет, и все эти отчеты надо объединить перед сортировкой и отображением главной рабочей ролью (Master Worker).
Создание и публикация рабочей роли
Закончив прототип и планирование высокоуровневой архитектуры, создайте необходимый проект в Visual Studio 2010 и опубликуйте его в Windows Azure.
Создание рабочей роли F# — не столь простой процесс, как хотелось бы, поэтому давайте разберем все необходимые этапы. Сначала вам потребуется скачать ранее упомянутые шаблоны Windows Azure F#. Затем вы должны создать проект Visual F# для Windows Azure. Я присвоил проекту имя AzureFSharpProject.
После этого у вас появится возможность создать рабочую роль F#, как показано на рис. 6.
Рис. 6. Создание рабочей роли F#
В этот момент вы можете поместить свою функцию сопоставления в роль Map Worker, а функцию сокращения в роль Reduce Worker. Затем создайте дополнительные рабочие роли для других ролей Map Worker и Reduce Worker в зависимости от масштаба ваших потребностей в обработке данных. Канонический справочник — документ Google MapReduce по ссылке labs.google.com/papers/-mapreduce.html. В нем подробно описываются архитектура MapReduce, возможные проблемы и сценарии применения.
Когда вы будете готовы к публикации в Windows Azure, щелкните правой кнопкой мыши свой проект и выберите Publish | Create Service Package Only, как показано на рис. 7.
Рис. 7. Публикация в Windows Azure
Наконец, вам потребуется зарегистрироваться на портале управления Windows Azure и через его интерфейс создать рабочую роль (рис. 8).
Рис. 8. Конфигурирование новой рабочей роли
В этот момент вы можете подключать свои узлы так, как считаете нужным, и обрабатывать алгоритмом MapReduce журналы в облаке. Конечно, этот же подход легко применим к источникам данных, отличных от простых файлов журналов. Универсальный F#-алгоритм MapReduce — наряду с интерактивными средствами, которые я продемонстрировал при его кодировании, — можно использовать практически для любой работы, связанной с разбором, сопоставлением и сокращением.
Дальнейшие шаги
F# — мощный язык программирования, который позволяет решать многие задачи с помощью как небольших блоков кода, так и более сложных программ, составляемых из этих блоков. В этой статье я продемонстрировал, как, написав всего 50 строк кода на F#, можно превратить алгоритм MapReduce в анализатор журналов на основе Windows Azure.
Что касается реализации MapReduce в Windows Azure, то, вероятно, вам стоит прочитать еще пару интересных статей по этой тематике. Сначала обратите внимание на статью «Building a Scalable, Multi-Tenant Application for Windows Azure» в MSDN, где обсуждаются рабочие роли и MapReduce (msdn.microsoft.com/library/ff966483). Потом прочтите статью Хуана Диаз (Juan Diaz) «Comparison of the use of Amazon’s EC2 and Windows Azure, cloud computing and implementation of MapReduce», в блоге по ссылке (bit.ly/hBQFSt).
Если вы еще не освоили F#, то, надеюсь, эта статья подтолкнет вас к тому, чтобы попробовать поработать на этом языке. А если вам интересно прослушать все интервью Дона Сайми (Don Syme), отправляйтесь в блог Simple-Talk (bit.ly/eI74iO).
В ближайших пару недель должен появиться недорогой инструмент, позволяющий загружать "самодельные" приложения на Windows Phone 7.
Корпорация Microsoft вместе с нашумевшей своими подходами к вопросу установки приложений на WP7 командой ChevronWP7 unlock team объявили ещё в июне, что они объединяются для разработки нового недорогого инструмента для разработчиков, позволяющего разблокировать смартфоны WP7.
Такая утилита позволит разработчикам загружать собственные приложения в обход Marketplace, и сделает весь процесс разработки и отладки приложений более быстрым и простым. Кроме того, такое решение также окажется в 11 раз дешевле существующего ныне способа загрузки ПО на телефон: за утилиту будут просить всего $9, в то время как регистрация разработчика на Windows Phone Marketplace стоит $99 в год. ChevronWP7 unlock team сообщает, что их приложение "Labs" будет весьма простое в использовании, и приводит следующую инструкцию:
Для регистрации понадобится Windows Live ID;За каждый конкретный WP7 смартфон будет взыматься плата в размере $9; оплатить можно кредиткой, либо через PayPal;После оплаты нужно будет загрузить и установить приложение;С помощью загруженного приложения WP7 смартфон ставится в очередь на разблокировку, управляемую ChevronWP7 unlock team;Вы получаете разблокированный смартфон, позволяющий вам загружать собственные XAP-файлы, и самодельные приложения.
Команда энтузиастов ChevronWP7 также предполагает, что утилиту будут использовать "для пиратства". "Мы знаем, что нашу работу порой ошибочно интерпретируют как поощрение разлочки устройств в пиратских целях", – сказал представитель ChevronWP7. "Это не тот случай. Наша цель – помочь ярким людям разрабатывать удивительные вещи, не ущемляя сообщество разработчиков ограничениями, накладываемые на приложения в Marketplace".
Ранее Microsoft уже блокировала утилиту ChevronWP7, позволяющую разблокировать первую версию WP7 для установки на смартфоны приложений из XAP-файлов. Позже представители Редмонда встретились с Рафаэлем Ривьерой (Rafael Rivera) и Лонгом Зенгом (Long Zheng) – представителями ChevronWP7 unlock team – чтобы обсудить разрабатываемую ими утилиту и планы софтверного гиганта по поддержке "самодельных" приложений для Windows Phone 7.
ChevronWP7 unlock team прославилась тем, что в конце ноября прошлого года выпустила утилиту для разблокировки WP7 смартфонов. Впрочем, "жила" она не очень долго… спустя 2 недели после релиза разработчикам пришлось прикрыть проект из-за запроса из Microsoft.
Windows, как настольная операционная система, обеспечивает работу компьютеров и помогает максимально эффективно использовать современные технологии. Функции Windows 7 поддерживают такие задачи, как сетевые подключения, обеспечивающие доступ настольных систем к Интернету; используются приложения, позволяющие информационным работникам собирать и обмениваться знаниями, анализировать бизнес-данные и общаться с партнерами, клиентами и коллегами в реальном времени.
Windows — это также надежная серверная ОС, составляющая основу множества центров обработки данных. Windows Server предоставляет все нужное, от служб файлов и печати до виртуализации с Hyper-V to для работы веб-сайтов с IIS.
Однако наибольшая польза Windows часто реализуется при объединении функций платформ сервера и клиента для создания полного решения для бизнес-задач. Используя существующие компоненты платформ клиента и сервера Windows, можно создать несколько полных решений. Также доступны ценные ресурсы, помогающие в выполнении процесса создания этих решений.
Эффективное подключение
DirectAccess с Network Access Protection (NAP) предоставляет надежное практическое решение, основанное на интеграции различных компонентов Windows. DirectAccess подключает клиентские компьютеры к ресурсам интрасети без сложностей виртуальной частной сети (VPN). Подключение осуществляется прозрачно; также предоставляется возможность простого и эффективного удаленного подключения, сохраняя необходимую безопасность для защиты внутренних ресурсов.
DirectAccess с NAP также предоставляет средства текущей проверки работоспособности для удаленных компьютеров (не только при установлении подключения к удаленному компьютеру, как в решении VPN). Также до подключения удаленных пользователей обеспечивается соответствие требованиям к работоспособности системы.
По умолчанию клиенты DirectAccess используют сертификат компьютера для одноранговой проверки подлинности IPsec (Internet Protocol security). С DirectAccess и NAP сертификат проверки подлинности для доступа к интрасети является сертификатом работоспособности. Этот сертификат работоспособности проверяет удостоверение клиентского компьютера DirectAccess и удостоверяет, что клиент DirectAccess соответствует требованиям к работоспособности системы.
Решение DirectAccess с NAP использует ряд инфраструктурных компонентов Windows для предоставления этих функций (см. рис. 1). В число компонентов входят следующие.
Службы доменов Active Directory (AD DS): Предоставляют принадлежность к домену для клиентов и серверов DirectAccess, проверку подлинности компьютера и учетных данных пользователя, а также распространяет параметры групповой политики клиентам DirectAccessИнфраструктура открытых ключей (PKI): Распространяет цифровые сертификаты клиентам DirectAccess, серверам DirectAccess и веб-серверам для DirectAccess с NAP, один центр сертификации (CA) выпускает сертификаты компьютеров, а отдельный ЦС на основе Windows, называющийся ЦС NAP, выпускает сертификаты работоспособностиСервер DirectAccess: Компьютер под управлением Windows Server 2008 R2 размещает подключения DirectAccessСервер сетевых расположений: Компьютер обычно под управлением Windows Server 2008 или более поздней версии и IIS для размещения безопасного веб-сайта, чтобы клиенты DirectAccess могли определять подключение к интрасетиСервер политики работоспособности NAP: Компьютер под управлением Windows Server 2008 или более поздней версии и сервер сетевых политик (NPS) осуществляет ведение журнала и проверку состояния системыЦентр регистрации работоспособности (HRA): Компьютер под управлением Windows Server 2008 или более поздней версии и IIS, получающий цифровые сертификаты от ЦС NAP для соответствующих требованиям клиентов DirectAccessСерверы исправлений: Компьютеры, предоставляющие обновления или ресурсы, необходимые несоответствующим требованиям клиентам DirectAccess для обеспечения соответствия требованиям к работоспособности системы. Примеры включают серверы службы обновления программного обеспечения Windows (WSUS) и серверы распространения сигнатур защиты от вредоносных программ
Рис. 1. Компоненты инфраструктуры решения DirectAccess с NAP.
Учитывая эти компоненты инфраструктуры, кратко рассмотрим работу решения DirectAccess с NAP. При запуске клиент DirectAccess входит в систему домена AD DS и отправляет информацию о текущей работоспособности HRA. Затем HRA отправляет информацию о состоянии работоспособности клиента DirectAccess серверу политики работоспособности NAP.
Сервер политики работоспособности NAP оценивает информацию о состоянии работоспособности клиента DirectAccess, определяет его соответствие требованиям и отправляет результаты HRA. Если клиент DirectAccess не соответствует требованиям, результаты включают инструкции по исправлению состояния.
Если состояние работоспособности соответствует требованиям, HRA получает от PKI сертификат работоспособности и отправляет его клиенту DirectAccess. Теперь клиент DirectAccess может создать туннель интрасети с сервером DirectAccess.
Если состояние работоспособности не соответствует требованиям, HRA не выпустит сертификат работоспособности. Клиент DirectAccess не может создать туннель интрасети с сервером DirectAccess, поэтому доступ эффективно заблокирован. Однако у клиента DirectAccess имеется доступ к серверам исправлений для исправления состояния.
При необходимости клиент DirectAccess обращается к серверам исправлений для получения необходимых обновления для обеспечения соответствия. ПО завершении этого процесса клиент DirectAccess обновляет свою информацию о работоспособности и отправляет ее HRA. HRA отправляет серверу политики работоспособности NAP обновленные сведения о работоспособности. Если установлены все необходимые обновления, сервер политики работоспособности NAP определяет соответствие клиента DirectAccess требованиям и отправляет результаты проверки HRA.
Затем HRA получает сертификат работоспособности от ЦС NAP и отправляет его клиенту DirectAccess. Теперь клиенрт DirectAccess может использовать сертификат работоспособности для проверки подлинности с целью доступа к интрасети, используя сервер DirectAccess.
Результатом, на основе сочетания компонентов Windows, являются мобильные сотрудники. Теперь они могут эффективно получать доступ к внутренним ресурсам, одновременно сохраняя безопасность и целостность внутренней сети.
Дополнительные сведения о решении DirectAccess c NAP см. в полном руководстве по решению, доступном в библиотеке TechNet. Также доступны тестовые руководства по DirectAccess с NAP . В этих тестовых руководствах описаны и задокументированы все необходимые этапы создания рабочей лабораторной среды для демонстрации решения и экспериментов с ней.
Создание интегрированных решений
Также доступны тестовые руководства для ряда других решений инфраструктуры Windows. Например, доступно тестовое руководство по альтернативным конфигурациям решения DirectAccess с NAP, включая использование Forefront Unified Access Gateway с DirectAccess и NAP.
Начните с лаборатории тестирования базовой конфигурации, которая поможет создать базовую конфигурацию, с которой можно экспериментировать с новыми решениями в контролируемой среде. На основе этой базовой конфигурации доступны дополнительные тестовые руководства.
После создания базовой конфигурации можно приступить к изучению других интегрированных решений. В других тестовых лабораториях рассматриваются новые сетевые протоколы IPv6 и DHCPv6. Протокол IPv6 предназначен для решения множества проблем текущей версии протокола Интернета (IPv4), таких как исчерпание адресов, безопасность, автоматическая настройка и расширяемость.
В тестовом руководстве IPv6 демонстрируются следующие сценарии:
Поведение IPv6 по умолчанию и связь в интрасети только с IPv4Подключения в интрасети на основе IPv6 с использованием протокола ISATAPПодключения в интрасети на основе IPv6 с использованием собственной адресации IPv6Подключение IPv6 в имитируемой интрасети только с IPv4 с использованием 6to4
После ознакомления с IPv6 в расширение лаборатории DHCPv6 рассматривается поэтапный процесс динамического выпуска и управления адресами IPv6.
Тестовые руководства опубликованы на платформе TechNet Social, поэтому они открыты для расширения сообществом. Взгляните на Тестовая лаборатория по удаленному доступу VPN для Windows Server 2008 R2 как пример. Не все организации готовы к развертыванию решения DirectAccess, которое обсуждалось ранее. В этом тестовом руководстве рассматривается развертывание более традиционного подключения VPN, позволяющего удаленным пользователям устанавливать защищенные подключения по запросу к внутренней сети.
Тестовое руководство расширено участниками сообщества для демонстрации использования пакета администрирования диспетчера подключений (CMAK) с решением VPN, использование переподключения VPN и многого другого. Наконец, расширение за пределы решений основано только на основных компонентах инфраструктуры Windows; доступны тестовые руководства для ряда других инфраструктурных продуктов, включая System Center Service Manager 2010, Forefront Identity Manager 2010, SQL Server 2008 R2 и многое другое.
Создание интегрированных решений путем объединения платформ сервера и клиента Windows помогает раскрыть потенциал существующих вложений в технологии. Для получения дополнительных сведений по созданию интегрированных решений Windows посетите блог тестовых руководств по адресу blogs.technet.com/b/tlgs.
ОС Windows Server менялась много раз: выходили разные версии, предоставлялись разные уровни поддержки и предлагались различные методы устранения неполадок. В текущей политике поддержки утверждается, что отказоустойчивые кластеры Windows Server 2008 или Windows Server 2008 R2 официально поддерживаются командой поддержки Microsoft, если они отвечают определенным требованиям:
Все аппаратные и программные компоненты должны отвечать требованиям для получения логотипа «Certified for Windows Server 2008 R2».Готовое решение должно пройти проверочный тест в отделе Failover Cluster Management.
Получив официальную поддержку своего решения, вы можете быть практически уверены, что все будет работать. Всегда возможны трения с поставщиками оборудования и может потребоваться помощь Microsoft при настройке некоторых конфигураций, но главное — ваша решимость идти до конца. В этой статье я расскажу о наиболее типичных неполадках отказоустойчивых кластеров Windows Server 2008 R2 и о том, как их устранять.
Эти изменчивые кластеры
В Windows Server 2008 R2 понятие кластера серьезно поменялось благодаря появлению мастера проверки кластеров Cluster Validation .aspx, который входит в состав компонента Failover Clustering. Мастер проверки кластеров позволяет выполнить ряд специализированных тестов на подмножестве серверов, которые предполагается использовать в качестве узлов кластера.
При этом прямо и по отдельности проверяется все оборудование и ПО. В результате вы получаете оценку, насколько хорошо данная конфигурация поддерживает отказоустойчивую кластеризацию. Выполнение мастера на работающем кластере также позволяет узнать, выполняете ли вы рекомендации производителя. Мастер также нужно выполнять при добавлении нового оборудования или драйверов в кластер.
Для тех, кто предпочитает сценарии, в отказоустойчивых кластерах теперь поддерживается Windows PowerShell. Эту оболочку придется изучить, так как CLUSTER.EXE больше не обновляется. Если вы не знаете, что такое командлеты и для чего они нужны, можете выполнить команду Get-Help *Cluster*. Она предоставит список с описанием команд, например такой:
Name Synopsis
—- ——–
New-Cluster Create a new failover cluster. Before you can create a
cluster, you must…
Если вы не знаете, как использовать командлет, можете воспользоваться командой Get-Help New-Cluster –Examples, чтобы увидеть примеры:
NAME
New-Cluster
SYNOPSIS
Create a new failover cluster. Before you can create a cluster, you
must connect the hardware (servers, networks, and storage), and run
the validation tests.
————————– EXAMPLE 1 ————————–
C:\PS>New-Cluster -Name cluster1 -Node node1,node2,node3,node4
Name
—-
cluster1
Description
———–
This command creates a four-node cluster named cluster1, using default
settings for IP addressing.
При получении событий Windows всегда неплохо действительно понимать, что они означают. Некоторые не настолько наглядны, как того хотелось бы. Список событий, которые вы можете увидеть, доступен в Интернете на следующей странице.
Все начинается с журналов событий
При возникновении неполадки прежде всего надо смотреть в журнал событий Cluster. Любые критические и простые ошибки и предупреждения попадают в системный журнал. Информационные сообщения (например, о переходе группы в автономный режим, перенос группы на другой узел и т. п.) находятся в журнале Cluster Operational Channel. Эти события можно увидеть здесь: Event Viewer/Application and Services Logs/Microsoft/Windows/FailoverClustering.
Если вы не знаете, что не так с той или иной службой или группой, можете посмотреть журнал Failover Cluster Management. Если выделена определенная группа, выберите команду «Show Critical Events for this application». Если выделена определенный ресурс, выберите команду «Show Critical Events for this resource».
При этом откроется системный журнал, отфильтрованный для отображения событий соответствующей группы или ресурса. В нем будут сообщения всех экземпляров системного журнала всех узлов кластера. Это удобно, так как дает возможность увидеть всю картину с одного места.
Определив проблемный ресурс, вы можете перейти в системный журнал, чтобы просмотреть его на предмет других обстоятельств неполадки. Пусть вас не обманывают симптомы — сконцентрируйтесь на причине проблемы. Например, в случае сбоя сетевого имени или IP-адреса посмотрите, нет ли других связанных с сетью событий, которые могут приводить к этой неполадке (сбой стека TCPIP, неработоспособная сетевая карта и т. п.).
Журнал отладки кластера перенесен в сеансы трассировки событий. Файла CLUSTER.LOG больше нет — теперь система записывает информацию в ETL-файлы (extract, transform and load), размещенные в папке %WinDir%\System32\winevt\logs. Из этих ETL-файлов можно сгенерировать единый файл CLUSTER.LOG. Однако это снимок на определенный момент времени. Иначе говоря, при создании файла Cluster.log запись в оригинальный Cluster.log не производится. Каждый раз, когда вы генерируете этот файл на узле, он перезаписывает предыдущую копию.
Можно генерировать журналы командой Get-ClusterLog оболочки Windows Powershell. Она применяется ко всем узлам кластера и создает файл на каждом кластере в папке %WinDir%\Cluster\Reports. Для регулирования числа узлов и размера файлов применяются дополнительные параметры.
Допустим, у вас кластер из девяти узлов и вы хотите получить все журналы. Можете воспользоваться параметром –Destination — будут сгенерированы все журналы и скопированы в указанное место. Они все попадут в одно указанное вами место. В имени файла будет указано имя узла (например, команда Get-ClusterLog –Destination c:\logs создаст файлы <имя_узла_1>_Cluster.log, <имя_узла_2>_cluster.log и т. д. в папке C:\LOGS).
Если нужно выяснить, легко ли воспроизводится неполадка, воспользуйтесь параметром периода времени –Timespan (в минутах). Просто воспроизведите неполадку на узле и выполните команду Get-ClusterLog –Timespan 5 –Node <имя_узла_1>. Она сгенерирует Cluster.log только для узла 1 и только за последние пять минут.
Вот некоторые советы по устранению неполадок на таком уровне:
Этот журнал подробный и сложный и это должно быть не самое первое место, в котором надо искать информацию.Позаботьтесь о записи данных как минимум за последние три дня. В этом случае если сбой произойдет в пятницу, при выходе на работу в понедельник данные все еще будут доступны. Каждый журнал занимает 100 МБ. Если надо увеличить этот размер, используйте в Windows Powershell команду Set-Clusterlog –Size 200 (можете указать другой, более подходящий вам размер).Некоторые приложения слишком «шумные» или «многословные», когда речь идет о записях в журналах. В этом случае также придется увеличить размер журнала.В журнале отладки кластера используется время GMT, поэтому придется преобразовывать время в локальное.Если журналы должны быть в определенном месте или охватывать определенное время, используйте соответственно параметр –Destination или –Timespan.
В следующем выпуске мы поговорим о некоторых стандартных сценариях устранения неполадок.
С 6 по 8 октября в Москве в первом российском частном парке Digital October (бывшая территория фабрики «Красный Октябрь») на Берсеневской набережной проходила 5-я юбилейная конференция User eXperience (UX) Russia 2011. Точнее, конференция проходила первые два дня, а в субботу был день мастер-классов, которые проходили на Крылатских холмах и на Краснопролетарской улице.
Если в 2010 году UX Russia 2010 из-за ограниченного количества мест не все желающие смогли посетить мероприятие, то в этом году организаторы постарались на славу: участников ждали главный зал конференции, вмещающий 400 человек, и три аудитории поменьше.
Театр, как известно, начинается с вешалки, а конференция с улыбающихся девушек, которые выдавали бэйджи и инфопаки участникам .
Перед началом мероприятия участники, чтоб окончательно проснуться, могли попить кофейку или чайку, закусив пирожным.
Конференцию открыл генеральный директор USABILITYLAB Дмитрий Сатин, который с прискорбием напомнил, что предыдущим вечером Apple и вообще весь IT-мир потерял выдающуюся личность, фигуру, потерял Стива Джобса. Но, тем е менее, потеряв человека Стива Джобса, Apple обрела легенду Стива Джобса, – отметил Дмитрий Сатин.
Поблагодарив организаторов конференции, Дмитрий Сатин озвучил число участников, которых оказалось около 500 человек, больше, чем в предыдущем году, что не может не радовать. Сообщество UX, по словам Дмитрия Сатина, начало «самовоспроизводиться». Спонсоров и партнёров оказалось так много, что, сверившись со «шпаргалкой» решили отметить только неизменного платинового спонсора, компанию Microsoft, которая не только поддерживает конференцию, но и присылает превосходных докладчиков.
Главное слово, красной нитью проходившее через все доклады конференции – usability. Это лейтмотивом звучало и в докладе Меган Донахью, главы разработчиков и UX-менеджеров команды MS Windows Phone Design.
…и Алексея Тарасова (Группа компаний BLOCK), который считает этот термин вполне применимым к рекламе, и в выступлениях других докладчиков.
Отмечу хорошую организацию зоны отдыха, где уставшие от сидения на стульях могли отдохнуть, удобно плюхнувшись в кресло, попить водички и там же послушать и посмотреть на больших экранах трансляцию докладов из главного зала.
Во время кофе-брейка я заметил небольшую толпу народа, увлечённо что-то разглядывающую. Пробившись с ним с чашечкой кофе в руке, я увидел невысокое симпатичное электронное существо, мелкими перебежками пытающееся ретироваться от обступивших его зевак.
Я протиснулся поближе, и тут аппарат, похожий на небольшого циклопа из-за наличия всего одного глаза-камеры на «голове», нацелился на меня, подумал, стоит ли с таким говорить, но потом решился и сказал: «Кажется, я Вас сегодня уже видел». Когда я наклонился ниже, девайс, как мне показалось, проникновенно произнёс: «Угостите робота кофе?». Ну, а когда я с трудом, давясь от смеха и пытаясь не расплескать кофе достал из кармана фотоаппарат и сделал несколько снимков, то отвернувшийся было робот, повернув «голову» обратно, бросил: «Ну что, получилась фотография?». Тут, конечно, засмеялись все. Существо, как выяснилось, звали R.Bot 100. Устав общаться с дотошными любопытствующими, робот развернулся и пробурчав что-то о необходимости подзарядки, поплыл к одной из стен, где была его док-станция.
Не обошлось без казусов. Так, Меган Донахью, тренируясь перед началом конференции управляться с презентационным пультом, вдруг сказала: «Oops… It’s stuck!». Как выяснилось, презентация висла из-за различия версий PowerPoint презентации Меган и стоявшей на лекционном компьютере.
К сожалению, послушать удалось не всё, что хотелось. Звонок с работы вернул меня из мира цифрового в реальный, который, как ни странно, показался гораздо более неприглядным.
Кому довелось иметь дело со службами терминалов в Windows Server 2003, не удивляются тому, что нет уверенности в том, какие сценарии поддерживает та или иная роль службы удаленных рабочих столов (Remote Desktop Services, RDS). Не все до развертывания выполняют полноценное проектирование — часто решение вопросов откладывают на потом.
RDS в Windows Server 2008 R2 достаточно сильно отличается от служб терминалов Windows Server 2003. Более ранняя версия поддерживала лишь сервер терминалов и сервер лицензий в редакции Standard.
RDS поддерживает сеансы и управление лицензиями, а также в ней появилось большое количество улучшений в работе пользователя и в функциях управления лицензиями. Кроме того, поддерживается виртуальная машина (VM), а также серверные роли для облегчения обнаружения, посредничества в соединении, фермы серверов (для крупномасштабных развертываний и избыточности) и безопасный доступ к WAN.
В течение последующих нескольких месяцев вы узнаете, с чего начинать работу с RDS, используя знакомые сценарии, как, например, доставка сеанса отдельного сервера, и перейдете к новинке в Windows Server 2008 R2 – виртуальной инфраструктуре рабочего стола (Virtual Desktop Infrastructure, VDI). Затем мы изучим более емкие сценарии развертывания с помощью ферм серверов RD Session Host и посредника соединений RD Connection Broker, разрешения обнаружений с помощью RD WebAccess и сценарии разрешения доступа к WAN посредством шлюза RD Gateway.
Доставка сеанса одного сервера
Сервер узла сеансов удаленных рабочих столов (RD Session Host), ранее известный как сервер терминалов (Terminal Server), — это серверная роль RDS. Она умеет «доставлять» рабочий стол целиком или отдельные приложения, так называемые приложения RemoteApp. Это идеальный вариант для высоко масштабируемой доставки приложений. Приложения могут запускаться независимо друг от друга многочисленными пользователями, которые вошли в систему сервера RD Session Host.
Несмотря на то, что для административных целей сервер Windows может принять два одновременных входящих соединения RDP, лишь RD Session Host способен поддерживать более двух удаленных соединений, предоставляя все дополнительные возможности протокола удаленных рабочих столов (Remote Desktop Protocol, RDP) 7.
Для небольших сред, например для небольшой компании или филиала, лучше всего подойдет один сервер. Это также и самый простой сценарий развертывания RDS. Только нужно помнить следующее:
У одного сервера есть ограничения по количеству открытых сеансов.Отсутствие избыточности отрицательно скажется на всех соединениях, если сервер потерпит сбой.Включение узла сеансов удаленных рабочих столов
Чтобы разрешить использование сервера RD Session Host, прежде всего на Windows-сервере надо установить роль RDS. Затем устанавливают службу RD Session Host. Завершив установку, нужно сделать следующее:
Определитесь, необходима ли для входа аутентификация NLA (Network Level Authentication). NLA позволяет пользователям проходить аутентификацию до открытия сеанса на сервере RD Session Host. Это одновременно позволяет ускорить вход и обеспечивает защиту от атак типа «отказ в обслуживании» (Denial of Service, DoS).В группу пользователей удаленных рабочих столов (Remote Desktop Users) добавьте те группы пользователей, которым будет разрешен доступ к серверу RD Session Host.Настройте параметры пользовательского интерфейса, разрешив (или запретив) воспроизведение аудио и видео, запись аудио и изменение композиции рабочего стола (Desktop Composition) (разрешение композиции рабочего стола автоматически разрешает возможности Aero).Задайте режим лицензирования сервера. Для подключения к серверу RD Session Host каждому пользователю и устройству нужна лицензия. Выберите для этих соединений лицензирование «на пользователя» или «на устройство». Лицензирование сервера не обязательно настраивать сразу же, поскольку есть льготный период.
Клиентская часть настраивается просто. Клиент соединения с удаленным рабочим столом (Remote Desktop Connection, RDC) входит в состав ОС Windows. Если используется более ранняя версия ОС, чем Windows 7, то для получения максимально удобного пользовательского интерфейса следует установить последнюю версию клиента RDP. Загрузить последнюю версию клиента можно с веб-сайта Microsoft
Лицензионные требования
По окончанию льготного периода лицензирования для каждого пользователя или устройства необходимо получить лицензии на подключение к серверу RD Session Host. Кроме того, нужно установить сервер лицензирования (RD Licensing). Службу RD Lisensing можно установить на этот же сервер или на отдельный, это не важно.
Потребуется приобрести лицензии клиентского доступа (RDS Client Access Licenses, CAL) и установить их на сервере RD Licensing. Эти лицензии привязываются к серверу, но RDS позволяет при необходимости перемещать их на новое оборудование. Нельзя забывать о том, что RDS поддерживает оба типа лицензирования – на пользователя и на устройство. При выборе модели надо исходить из того, чего у вас больше — пользователей или компьютеров. RDS не поддерживает лицензирование обоих типов одновременно, и выбранные лицензии должны совпадать с режимом работы сервера RD Session Host.
Закончив со службой ролей RD Session Host, установите службу ролей RD Licensing. Затем нужно сделать следующее:
Активируйте сервер RD Licensing.Установите клиентские лицензии RDS CAL таким образом, чтобы сервер RD Licensing мог назначать их пользователям и устройствам.Настройте RD Session Host на использование сервера RD Licensing (это нужно сделать, даже если службы ролей расположены на одной машине).Размер сервера
Среди тех, кто мало знаком с размещением сеансов, распространен вопрос о том, как много пользователей могут использовать сервер одновременно. К сожалению, на него не так легко ответить. Это определяется рядом факторов: какие используются приложения, типы обрабатываемых данных и другими.
Для получения реальных цифр многие оценивают размер на основе результатов пилотного проекта. Подробнее о практическом моделировании использования см. документацию и средство имитации нагрузки, созданные командой разработчиков RDS. К счастью, Windows Server 2008 R2 это 64-разрядная система, поэтому память больше не является узким местом, как это было в 32-разрядной версии.
Можно виртуализовать сервер RD Session Host, но это может привести к снижению числа одновременно поддерживаемых сеансов. Моделирование надо выполнять на машине того же типа (физической или виртуальной), которую предполагается использовать. Если же вы создали виртуальный сервер RD Session Host, лучше использовать сервер с процессором, поддерживающим трансляцию адресов второго уровня (Second-Level Address Translation, SLAT), чтобы снизить дополнительную нагрузку, возникающую из-за сопоставления памяти между физической и виртуальной машинами. Также для снижения нагрузки, рекомендуется использовать гипервизор первого типа, как например Hyper-V, а не второго.
Полноэкранные сеансы или приложения RemoteApps
Сервер RD Session Host поддерживает две модели доставки приложений: полные рабочие столы и программы RemoteApp, которые визуально интегрируются с локальным рабочим столом. Последние выглядят для пользователя как обычные локальные приложения. Отсутствие необходимости переключаться между двумя рабочими столами делает приложения RemoteApp наиболее подходящими для одновременной работы с локальными и удаленными приложениями.
Приложения RemoteApp, запущенные одним пользователем на сервере, работают в одном сеансе. Нужна всего лишь одна открытая копия профиля. Это снижает накладные расходы на сервере, так как для работы сеанса нужна лишь одна работающая копия процессов в ядре.
Вот вкратце рассказ о том, как использовать один сервер, зачем нужны сеансы, каковы различия между приложениями RemoteApp и сеансами, а также какова модель лицензирования RDS. В следующий раз я расскажу о Microsoft VDI.
Подробные инструкции по планированию и развертыванию RDS см. в книге Windows Server 2008 R2 Remote Desktop Services Resource Kit.
Традиционно считается, что консолидация всегда просто нужна для сокращения числа серверов в центре обработки данных. С тех пор мы поняли, что консолидация это не просто сокращение объема оборудования.
По хорошему, прежде чем думать о реальной консолидации оборудования, следует изучить все варианты консолидации рабочей нагрузки и оптимизации оборудования. Разговор дальше строится в предположении, что вы уже выяснили все эти нюансы и определились, как будет выглядеть ваш новый динамичный центр обработки данных.
Иногда оказывается разумным заплатить немного денег за поддержку устаревшего оборудования, чем заменять его новым. Это может показаться сложным для понимания, но многие сразу улавливают суть. Нужно просто соблюдать баланс ожиданий, затрат и технологий и выбирать оптимальное их сочетание.
Поддержка или замена
В качестве примера возьмем используемую только для разработки ферму виртуальных серверов. Исходные данные: разработчикам нужно создать ферму виртуальных серверов, на которой они могли бы тестировать новые приложения. Эта ферма не будет обслуживать пользователей из производственной среды. От нее не требуется доступность 24 часа семь дней в неделю. Вместе с тем, вы недавно по плану вывели из эксплуатации целую стойку блейд-серверов.
Вы тщательно посчитали затраты, и руководство решило, что компании невыгодно платить за расширенную поддержку этой стойки блейд-серверов. Планируется стереть диски этих серверов и заплатить сторонней организации, чтобы их вывезли и утилизировали. Это довольно популярный сценарий. Именно в таких ситуациях вы можете вмешаться и предоставить своей компании дополнительное рабочее пространство за небольшие деньги или вообще бесплатно.
При правильной консолидации рабочих нагрузок и оптимизации оборудования практически наверняка возникнет избыток оборудования, которое нужно выводить из эксплуатации. Именно оно попадает в список того, что нужно выбросить.
Однако новые технологии и новые процессы могут позволить использовать это оборудование для обеспечения новой ценности для компании. Так как же задействовать устаревшие стойки блейд-серверов и сами серверы для создания надежной платформы разработки, не тратя деньги на расширенную поддержку оборудования? Существует несколько вариантов. Допустим, вам досталась стойка с 14 серверами. Нужно создать многосерверную платформу разработки. В такой ситуации возможны два варианта консолидации.
Вариант №1. Кластеризация
В этом варианте серверная среда кластеризуется на нескольких аппаратных платформах. Создайте четыре серверных операционных системы на 12 блейд-серверах. Каждая ОС будет охватывать три блейд-сервера, причем два будут оставаться в автономном режиме и использоваться как «резерв».
При таком подходе вы получаете работающую операционную систему, даже если один из трех серверов потерпит сбой. В этом случае один из двух оставшихся блейд-серверов может подменить сбойный сервер на время его ремонта или замены. Принцип не нов.
С выходом Windows Server 2003 технологии кластеризации Microsoft значительно усовершенствовались. Есть также много сторонних поставщиков кластерных решений. Кластеризация предоставляет необходимые мощности, снижая при этом риск сбоя оборудования путем распределения операционной системы среди нескольких аппаратных платформ.
Вариант №2. Кластеризация с виртуализацией
Второй теоретический способ базируется на первом варианте, но при этом добавляется дополнительный уровень защиты, охватывающий всю стойку, а не только три блейд-сервера, используемых в первом варианте. Некоторые посчитают это излишеством, но оно стоит того, если у вас есть ресурсы.
Если оборудование исключительно экзотическое, а среда, в которой его планируется использовать, исключительно важна, этот вариант моментально превращается из излишества в необходимость. Дополнительный уровень защиты также может увеличить число серверов с четырех до восьми. С использованием виртуализации можно без проблем выполнить резервное копирование ОС с использованием моментальных снимков и практически без изменений переносить их между кластерами.
Кластеризация с виртуализацией хорошо работает в среде, где требуются дополнительные мощности, но нет желания продолжать платить за расширенную поддержку. Возможно, могут потребоваться дополнительные затраты на лицензии. Но даже такие дополнительные расходы оправданы, если речь идет о продолжении использования оборудования, которое в противном случае было бы просто выброшено.
Кроме того не забывайте, что консолидация оборудования не должна быть сложной. Независимо от того, строите ли вы ферму кластеризации на основе старой стойке или просто предоставляете своим разработчикам устаревшую серверную платформу, обеспечивающую более высокую производительность, вы выполняете кластеризацию. Иногда самые простые идеи являются самыми фундаментальными и представляют наибольшую ценность для бизнеса.
Предыдущие записи
Рубрики
Облако тегов
Записи RSS
Комментарии RSS
Последние 50 записей
Назад
Пустота 
Жизнь 
Земля 
Ветер 
Вода 
Огонь 
