Компонент Microsoft Hyper-V впервые был реализован в системе Windows Server 2008. Это решение предоставляет технологию виртуализации на основе гипервизора, которая обеспечивает производительность виртуальной машины, эквивалентную производительности системы, построенной на реальном оборудовании. Технология Hyper-V использует отказоустойчивую кластеризацию как механизм для создания виртуальных сред высокой надежности. Эта функция дает возможность перемещать виртуальную машину с одного узла на другой с минимальным временем простоя, за счет механизма быстрой миграции, который сохраняет оперативную память и состояние виртуальной машины на диск, приостанавливает виртуальную машину, отключает том LUN на исходном узле, подключает LUN на целевом узле, считывает информацию о памяти и состоянии обратно в виртуальную машину, а затем запускает последнюю. Этот процесс довольно быстрый, но обычно виртуальная машина перестает быть доступной на период около 30 секунд (или дольше, в зависимости от конфигурации), и сеанс связи для пользователей прерывается.

Одним из главных недостатков технологии Hyper-V в системе Server 2008 была невозможность перемещать виртуальную машину между узлами отказоустойчивого кластера с «нулевым» временем простоя. .

Проблема архитектуры Shared Nothing

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

Кластер состоит из множества узлов, на каждом из которых запущен экземпляр системы Windows Server. Но если тома NTFS используются в кластере, как обеспечить поддержку целостности NTFS и предотвратить появление множества параллельных подключений к тому NTFS? В отказоустойчивом кластере общие диски (то есть диски, путь к которым есть у каждого узла в кластере, они обычно представляют собой тома LUN в сети SAN) являются ресурсами кластера. Как и у других ресурсов в отказоустойчивом кластере, у этих ресурсов может быть только один владелец одновременно. Таким образом, к устройству LUN невозможно установить множество подключений, так как лишь один узел может владеть ресурсом. Владелец ресурса может подключить том LUN и получить доступ к хранящимся на нем разделам NTFS.

Рассмотрим решение Hyper-V, использующее отказоустойчивый кластер — в частности, виртуальные машины данного решения. Невозможность совместного использования тома LUN накладывает некоторые архитектурные ограничения. Гипервизор Hyper-V использует физические диски для хранения не только дисков виртуальных машин, но и различных конфигурационных файлов и файлов состояния. Если к тому NTFS одновременно может иметь доступ только один узел, любые виртуальные машины, которые совместно используют тома LUN для хранения дисков VHD и конфигураций, должны запускаться на одном и том же узле. Перемещать виртуальную машину, которая совместно использует том LUN с другой виртуальной машиной, невозможно — все виртуальные машины, совместно использующие LUN, должны перемещаться как единое целое. Это ограничение означает, что в системе Server 2008 каждая виртуальная машина должна иметь собственный LUN, чтобы перемещаться независимо от других виртуальных машин в кластере, при миграции отключая свой том LUN и подключая его на новом узле. Ограничение «одна виртуальная машина на LUN» означает, что администраторам придется иметь дело со множеством томов LUN, а также впустую расходовать дисковое пространство, так как каждый том LUN резервирует определенное количество памяти для расширения в будущем.

В дополнение к трудностям управления множеством томов LUN и неэффективного использования дискового пространства, еще одна проблема технологии Hyper-V в системе Server 2008 заключается в том, что при перемещении виртуальной машины необходимо отключать том LUN от исходного узла и подключать к целевому. Эти процессы отключения/подключения занимают много времени. Целью изменений, произведенных в системе Server 2008 R2, было создание механизма миграции виртуальных машин с «нулевым» временем простоя и незаметного для пользователей. Команда разработчиков Hyper-V внедрила механизм Live Migration для передачи памяти и информации о состоянии без остановки виртуальной машины. Однако отключение и подключение тома LUN, который содержит диск виртуальной машины, требует остановки дисков VHD, что приводит к простою. Чтобы избавиться от необходимости отключения и подключения во время перемещения и для обхода ограничения «один LUN на виртуальную машину», а также для экономии места, предотвращения административных проблем, а главное, экономии средств, необходимо иметь том LUN, к которому могут получать доступ сразу все узлы в кластере.

Общий том кластера Cluster Shared Volume

Хотя у механизма общего доступа в системе NTFS есть рассмотренный выше недостаток, в сетях SAN нет проблем с обработкой множества параллельных подключений к томам LUN, а следовательно, необходимы изменения только в файловой системе или в алгоритме получения доступа к ней. Один из вариантов — создание совершенно новой файловой системы, поддерживающей кластеры. Однако для реализации такого решения необходимы длительные периоды разработки и тестирования, к тому же появление новой системы сведет на нет поддержку и доверие, заработанные системой NTFS. Другое решение — переработка системы NTFS и ее механизмов обработки обновлений метаданных. Однако такое изменение NTFS окажется непомерно сложной задачей и потребует множественных изменений в операционной системе Windows, а также во многих приложениях и службах, которые используют NTFS, не говоря уже о том, сколько времени потребуется для проведения дополнительного тестирования.

Специалисты Microsoft решили описанную проблему и сделали систему NTFS совместно используемой, вообще не изменяя файловую систему, это выглядит очевидным решением, хотя его реализация сложнее, чем кажется. Система Server 2008 R2 достигает этой цели за счет введения технологии Cluster Shared Volume.

Проблемы с параллельным доступом в системе NTFS обусловлены подходом к обработке изменений метаданных — изменений, оказывающих влияние на структуру файловой системы, например изменение размера файла. Когда множество сущностей обновляют метаданные одновременно, возникает риск повреждения данных. Технология Cluster Shared Volume решает эту проблему, для каждого общего тома назначая владельцем (то есть координатором) один из узлов кластера. Данный узел выполняет все обновления метаданных в томе, в то время как остальные узлы осуществляют прямые операции ввода-вывода, которые являются основным видом доступа при работе виртуальных машин с диском, например при чтении содержимого диска VHD или записи на него. Общий том кластера локально подключается к узлу-владельцу, и поэтому у данного узла есть полный доступ к нему. Каждый диск общего тома имеет собственного владельца, при этом один узел не обязательно назначается владельцем каждого диска общего тома в кластере. Различные узлы могут быть владельцами различных общих томов. Выбор владельца по своей природе динамичен. Если узел-владелец будет отключен или выйдет из строя, другой узел автоматически станет владельцем для любых дисков общих томов кластера на этом узле.

Если механизмы Cluster Shared Volume активированы, разделение между операциями изменения метаданных и обычными операциями ввода-вывода достигнуто за счет внедрения фильтра общего тома кластера в стек файловой системы на каждом узле кластера. Когда узлу, который не является владельцем, необходимо произвести изменения в метаданных, например увеличить размер файла на динамическом диске VHD, эти метаданные (обычно небольшого размера) перехватываются фильтром общего тома кластера и посылаются по сети кластера узлу-владельцу, который производит обновление метаданных от имени узла-невладельца. Для обмена данными между владельцами и невладельцами механизмы Cluster Shared Volume используют ту же сеть, по которой передается информация о состоянии кластера (то есть сеть кластера). Узлы, не являющиеся владельцами, могут выполнять операции ввода-вывода для томов LUN напрямую, так как фильтр общего тома создает для каждого диска общего тома кластера карту секторов, которая показывает, где находятся данные того или иного файла. Эта карта совместно используется всеми узлами кластера, что дает им прямой доступ к нужным секторам.

Как показано на рисунке 1, оба узла соединены с хранилищем. Однако на самом деле тома LUN локально подключены к узлу-владельцу, который может выполнять действия как с данными, так и с метаданными, в то время как узел, не являющийся владельцем, может выполнять только прямые операции ввода-вывода, такие как чтение и запись блоков данных.

 

Рисунок 1. Архитектура общего тома кластера

Важно отметить, что технология Cluster Shared Volume разработана специально для обработки рабочих процессов виртуальных машин на базе гипервизора Hyper-V. Таким образом, это решение было оптимизировано под механизмы, используемые виртуальными машинами для доступа к хранилищу. Общие тома кластера не должны использоваться для каких-либо целей, помимо хранения виртуальных машин Hyper-V, и не поддерживают хранение данных других типов. Когда вы включаете общие тома для отказоустойчивого кластера через оснастку управления отказоустойчивыми кластерами в консоли MMC, в появившемся диалоговом окне необходимо принять условия и ограничения, которые сводятся к тому, что общий том кластера можно использовать только для файлов, созданных механизмами Hyper-V.

Фильтр Cluster Shared Volume предоставляет дополнительный путь доступа к хранилищу внутри отказоустойчивого кластера. Обычно фильтр перехватывает операции с метаданными и пересылает запросы узлу-владельцу для выполнения запрошенных операций, однако он также может перехватывать все операции ввода-вывода, выполненные на диске общего тома кластера, и отправлять их по сети кластера узлу-владельцу. Когда выполняется перехват всех операций ввода/вывода, диск общего тома кластера находится в режиме переадресации.

В любом решении высокой доступности следует устранить все критические точки отказа. Многопутевой ввод-вывод (MPIO) — отличное решение, позволяющее иметь множество путей к хранилищу, — устраняет точку отказа при доступе к хранилищу. Проблемы все равно могут возникать, а многие решения не используют MPIO, вот где режим переадресации может спасти ситуацию. Если узел потеряет прямое подключение к тому LUN, на котором располагается диск общего тома кластера (обычно из-за проблем соединения с сетью SAN, в которой располагается том LUN), то механизм доступа к общему тому автоматически переключится в режим переадресации до того момента, пока узел не восстановит прямое подключение к LUN. Все это время операции ввода-вывода будут посылаться по сети кластера на узел-владелец и выполняться там, что позволит узлу, потерявшему связь с хранилищем, продолжать функционирование без остановки виртуальных машин (рисунок 2). В режиме переадресации по сети кластера пересылаются достаточно большие объемы данных. Это обстоятельство имеет большое значение при выборе характеристик сети кластера (например, 10 или 1 Гбит/с). В режим переадресации доступа к общему тому кластера переходит только узел, который потерял соединение с томом LUN. Узлы в кластере, сохранившие подключение, продолжат выполнять прямые операции ввода/вывода и задействовать сеть кластера только для пересылки метаданных узлу-владельцу.

 

Рисунок 2. Переадресация операций ввода-вывода в случае потери соединения

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

Требования Cluster Shared Volume

Технология Cluster Shared Volume не предъявляет никаких специальных требований, кроме наличия хранилища с общим доступом в отказоустойчивом кластере. Если к хранилищу открыт общий доступ, то его можно добавить в пространство имен общего тома кластера и предоставить доступ к нему всем узлам кластера одновременно. Однако при использовании Cluster Shared Volume, особенно в связке с функцией Live Migration, определенные требования предъявляются к сети. Когда вы используете механизмы Cluster Shared Volume, некоторые операции хранилища зависят от метаданных, пересылаемых по сети, а не предаваемых напрямую с узла в хранилище. Сеть должна обеспечивать малое время ожидания во избежание запаздывания дисковых операций, но обычно от нее не требуется высокой пропускной способности, так как в нормальных условиях трафик метаданных имеет небольшой объем.

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

Так как связь между узлами и общим томом кластера осуществляется по протоколу SMB, службы Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks должны быть включены на сетевом адаптере, который используется в сети кластера (как и на общем томе кластера). Также на сетевом адаптере рекомендуется отключить протокол NetBIOS over TCP/IP.

Убедитесь, что службы сервера и рабочей станции запущены, и что протокол NTML не выключен на узлах отказоустойчивого кластера. Хотя механизмы отказоустойчивого кластера использует исключительно протокол Kerberos для обычных операций, протокол NTML необходим для обмена данными с общим томом кластера по сети. Протокол NTML обычно отключается в Group Policy, поэтому проверка результатов Resultant Set of Policy (RSoP) в оснастке Group Policy поможет определить, включен ли данный протокол. Отличный способ проверки соединения между узлами по протоколу SMB — запуск команды

net use * \c$

на всех узлах.

Выбор сети кластера

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

При работе с отказоустойчивыми кластерами на базе системы Server 2008, как правило, существует несколько сетей, которые кластер может задействовать для внутреннего обмена, это создает дополнительную точку отказа. Чтобы избежать такой ситуации, драйвер Network Fault Tolerant (NetFT) автоматически выбирает сеть для внутреннего обмена на основе определенных параметров доступных сетей.

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

 

Экран 1. Свойства сети кластера

Чтобы просмотреть все свои сети, включая присвоенные им метрики, можно использовать новый модуль PowerShell Failover Clustering, появившийся в системе Server 2008 R2, следующим образом:

PS C:\> Import-Module FailoverClusters
PS C: > Get-ClusterNetwork | ft Name,
   Metric, AutoMetric
Name Metric AutoMetric
— ----- ----------
Client Network 1000 False
Cluster Network 100 False
iSCSI Network 10000 True
LM Network 110 False

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

Обратите внимание, что в моем примере параметр AutoMetric имеет значение false для клиентской сети, сети кластера и сети Live Migration. Я установил эти метрики вручную, чтобы убедиться, что драйвер NetFT всегда будет использовать сеть, которую я хочу, для внутренних обменов связи кластера и обращений к общему тому кластера.

Чтобы задать метрику, необходимо сначала создать объект-указатель, который будет указывать на сеть. Например:

$netobj = Get-ClusterNetwork "Cluster
Network"

Теперь, когда у нас есть объект-указатель, мы можем изменять его параметр Metric следующим образом:

$netobj.Metric = <задаваемое значение,
   например, 100>

Этот метод следует использовать с осторожностью. Обычно, если все остальные параметры заданы верно (к примеру, какие сети может задействовать кластер, какие сети предназначены исключительно для клиентской связи), не требуется менять метрики вручную.

Если вы используете функцию Live Migration в кластере, по умолчанию она будет использовать сеть с метрикой, имеющей второе по близости к «0» значение. Это позволяет избежать столкновения трафика Live Migration с внутренним обменом кластера и обращениями к общему тому кластера. Можно воспользоваться оснасткой управления отказоустойчивым кластером и указать, какие сети может использовать механизм Live Migration для каждой виртуальной машины (см. закладку Network for live migration в свойствах виртуальной машины).

Сети с отказоустойчивыми кластерами, использующими технологии Cluster Shared Volume и Live Migration, по сути, являются произведениями искусства, особенно когда используется еще и протокол iSCSI. В таких случаях в системе часто можно увидеть пять логических сетевых адаптеров, каждый из которых представляет несколько физических сетевых адаптеров, связанных вместе для обеспечения необходимых значений отказоустойчивости и производительности.

  1. Один сетевой адаптер для управления хостом Hyper-V.
  2. Хотя бы один сетевой адаптер для виртуальных сетей, используемых виртуальными машинами.
  3. Один сетевой адаптер для внутреннего обмена и обращений к общему тому кластера.
  4. Один сетевой адаптер для трафика Live Migration.
  5. Один сетевой адаптер для связи по протоколу iSCSI.

Более подробную информацию по существующим сетевым адаптерам можно найти в статье Microsoft TechNet «Hyper-V: Live Migration Network Configuration Guide» по ссылке technet.microsoft.com/en-us/library/ff428137(WS.10).aspx. В этой статье рассматриваются все используемые сетевые адаптеры, а также алгоритмы оптимального разделения различных видов трафика. Кроме того, я выкладываю информацию о конфигурациях сети кластера по адресу www.savilltech.com/videos/CSVDeepDive/CSVDeepDive.wmv.

Использование технологии Cluster Shared Volume

Пользоваться технологией Cluster Shared Volume просто. После добавления дискового накопителя к общему тому кластера его разделы появляются в качестве подкаталогов папки \%systemdrive%\

ClusterStorage и по умолчанию именуются как Volume1, Volume2 и так далее. Для узла, у которого диск С является системным, первый общий том будет иметь путь C:\ClusterStorage\Volume1, второй общий — C:\ClusterStorage\Volume2 (экран 2).

 

Экран 2. Структура каталога общего тома кластера

Каждый узел отказоустойчивого кластера имеет одинаковое пространство имен ClusterStorage, с одинаковыми разделами и содержанием. Можно переименовать каталог Volume с номером X, но нельзя менять имя папки ClusterStorage. Обратите внимание, что общему тому кластера не присваивается буква диска, поэтому нет ограничений, связанных с наличием/отсутствием свободных букв, и нет необходимости управления дисками через глобальный универсальный идентификатор (GUID). Ваши виртуальные машины и виртуальные жесткие диски помещаются в подкаталоги папки \ClusterStorage и используются как обычно. Никаких дополнительных действий не требуется — хотя это не означает, что нет факторов, которые стоит принять во внимание.

Чтобы обеспечить максимальную гибкость при размещении и миграции виртуальной машины в системе Server 2008, необходимо размещать каждую виртуальную машину на отдельном томе LUN. Благодаря технологии Cluster Shared Volume можно размещать все виртуальные машины и виртуальные жесткие диски на одном томе LUN с включенными механизмами Cluster Shared Volume. Но возможность разместить все диски VHD на одном томе LUN не означает, что вам следует делать это. Необходимо следовать стандартным правилам размещения данных приложений или баз данных, файлов журнала и операционной системы на разных дисках. Если все эти диски VHD разместить на одном общем томе кластера, будет сведена на нет защита данных, которую обеспечивает использование независимых дисков. Вместо этого для обеспечения лучшей защиты можно рассмотреть вариант с несколькими общими томами кластера, один из которых предназначен для хранения дисков VHD с операционной системой, другой — для хранения дисков VHD с файлами журнала, а третий — для хранения данных приложений или баз данных.

Производительность тоже играет важную роль. Нужно учитывать требования к количеству операций ввода-вывода в секунду (IOPS) у ваших виртуальных машин. Установка нескольких виртуальных машин на один том LUN упрощает управление и оптимизирует использование дискового пространства, однако вам необходимо объективно оценивать возможности тома LUN, чтобы удовлетворить требования к количеству операций ввода-вывода в секунду всех виртуальных машин, размещенных на данном томе.

Обслуживание общих томов кластера

Как я упоминал ранее, возможность каждого узла получить прямой доступ к блокам общих томов кластера повышает гибкость архитектуры, ее работоспособность и функциональность, но привносит некоторые сложности в обслуживание тома. Многие утилиты предполагают, что им будет предоставлен монопольный доступ к тому и его блокам при работе. Представьте, что на узле-владельце запущена дефрагментация диска, а тем временем другой узел делает запись в блок, который программа дефрагментации только что переместила, — ничего хорошего! Что касается службы резервных копий Volume Shadow Copy Service (VSS), утилиты Chkdsk и им подобных — ни один из этих процессов не будет работать, если несколько узлов будут делать записи в блоки на дисках, в то время как процесс резервного копирования или утилита пытаются запуститься.

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

Процедуры обслуживания, типа дефрагментации Inbox и проверки Chkdsk, следует выполнять через команду Repair-ClusterSharedVolume, которая автоматически переводит общий том кластера в режим переадресации, выполняет задания, а затем выводит общий том кластера из режима переадресации для восстановления нормальной работы.

Поставщики решений резервного копирования также имеют доступ к специальному вызову API — PrepareVolumeForSnapshotSet (). Этот вызов автоматически переключает общий том кластера в режим переадресации, а после выполнения операций резервного копирования отключает данный режим. Если вы делаете снимок VSS аппаратными средствами, то режим переадресации необходимо будет включить всего на несколько секунд. Однако, если снимок VSS выполняется программными средствами, общий том кластера может пробыть в режиме переадресации довольно долгое время, пока не закончится резервное копирование.

Мультисайты и использование Cluster Shared Volume

В системе Server 2008 появилась широкая поддержка мультисайтовых кластеров, объединяющих несколько подсетей. Однако сеть кластера, которая использует общие тома кластеров, должна быть сетью с единственной подсетью. Это означает, что, хотя все остальные сети, используемые кластером, могут пересекать подсеть, для сети кластера следует использовать что-то вроде растянутой виртуальной сети LAN (VLAN).

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

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

Проще, чем кажется

Использование технологии Cluster Shared Volume дает средам, построенным на основе гипервизора Hyper-V, необходимую гибкость при размещении виртуальных машин, а также возможность оптимизации использования хранилищ. Механизмы Cluster Shared Volume не меняют базовую файловую систему, а лишь делают том доступным для всех узлов в кластере одновременно. Таким образом, объем дополнительных знаний, который необходимо получить для использования возможностей Cluster Shared Volume, довольно мал, так как новый подход к управлению хранилищами использует те же инструменты и процессы, что применялись ранее.

Хотя обычно считается, что технологии Cluster Shared Volume и Live Migration совместно используются для обеспечения «нулевого» простоя при миграции виртуальных машин, необходимо помнить, что они вполне самостоятельны. Механизмы Cluster Shared Volume можно использовать, даже если не применяется функция Live Migration. В этом случае применение технологии Cluster Shared Volume все равно позволяет организациям упростить процесс управления хранилищами и оптимизировать использование дискового пространства, при этом обеспечивая гибкость при размещении виртуальных машин.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP