Средство диагностики памяти в Microsoft Windows Server 2008 и выше

Для целей проверки ОЗУ в MS Windows служит нативная команда-планировщик mdsched

C:\> mdsched

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

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

после окончания проверки, система автоматически перезагрузится в штатном режиме.

так выглядит утилита, которая обнаружила проблемы с ОЗУ:

по нажатию на функциональную клавишу F1, отобразится окно с настройками утилиты:

Результаты проверки на короткое время отобразятся в трее при загрузке профиля:

если же проблемы с памятью обнаружены, при входе в профиль будет показано следующее предупреждение:

Дополнительную информацию по проделанной проверке можно посмотреть в сборщике событий Event Viewer, журнал System. Также можно воспользоваться и PowerShell:

PS C:\> Get-EventLog System -After "22/04/2013 01:00AM" -Source Microsoft-Windows-MemoryDiagnostics-Results | select TimeGenerated,EntryType,InstanceID,Message | Format-List

TimeGenerated	 : 23.04.2013 4:35:31
EntryType		 : Information
InstanceId		 : 1201
Message			 : The Windows Memory Diagnostic tested the computer's memory and detected no errors

TimeGenerated	 : 23.04.2013 4:35:31
EntryType		 : Information
InstanceId		 : 1101
Message			 : The Windows Memory Diagnostic tested the computer's memory and detected no errors


PS C:\>

Поднятие Network Load Balancing кластера на базе Microsoft Windows Server 2012 внутри гипервизора VMWare ESX 5.0.

Кто хоть раз пытался поднять NLB внутри ESX наверняка сталкивался с рядом проблем и в итоге либо долго и мучительно копался решая их, либо вовсе отказывался от такой затеи. В этой статье я покажу что необходимо для работы представленной технологии внутри VMWare.

Подготовка среды VMWare ESX для работы технологии MS NLB

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

1. Переходим в VSphere в панель управления виртуальными свитчами: View -> Inventory -> Networking

2. Выбираем Port-group в которой будут находиться наши виртуалки и клацаем Edit Settings.

3. Изменяем три параметра: MAC Address Changes = Accept; Forged Transmits = Accept; Notify Switches = No.

Поднимаем кластер NLB внутри виртуальных машин VMWare ESX

Для этого нам понадобятся две виртуалки с развернутыми в них Windows Server 2012. Каждая виртуальная машина должна иметь по два сетевых адаптера в одном или разных VLAN-ах. Второй NIC нужен для того, чтобы была возможность подконнектиться к конкретной ноде, после того как кластер будет собран (нужен отличный от кластерного MAC адрес).

Сетевая конфигурация узлов до настройки (два адаптера в одной подсети)

1. Инсталлируем фичу NLB с помощью PowerShell

PS C:\> Import-Module ServerManager
PS C:\> 
PS C:\> Install-WindowsFeature NLB, RSAT-NLB # Инсталлируем сервис балансера и средства графического управления им

Success		Restart Needed	Eхit Code	Feature Result
-------		--------------	---------	--------------
True		No				Success		{Network Load Balancing, Remote Server Adm...

2. На узле 1 приступаем к конфигурированию кластера NLB

В главном меню оснастки Network Load Balancing Manager выбираем Cluster -> New

В поле Host вводим IP текущей ноды и нажимаем Connect

Далее в отобразившемся списке доступных интерфейсов выбираем тот, через который будет работать NLB

Если Вы заранее назначили интерфейсу NLB IP-адрес и остальные параметры, то на этом этапе просто жмем Next

Задаем виртуальный IP-адрес нашего кластера (ну или несколько IP-адресов)

Указываем параметры кластера. FQDN кластера также нужно прописать в DNS. Multicast прячет два MAC-адреса в одном, однако не все сетевое оборудование сможет работать в такой конфигурации (в частности известны проблемы с Cisco и у меня как раз такая ситуация, так что настраиваем Unicast)

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

После нажатия на Finish нужно какое-то время подождать. В итоге должен подняться и быть доступным по сети одноузловой кластер NLB. Выделенный (Dedicated) и виртуальный (Cluster) IP-адреса будут иметь единый виртуальный MAC.

3. Приступаем к добавлению второго узла в кластер

Предварительно на втором узле нужно установить фичу NLB точно также, как это делалось для первой ноды (см. пункт 1). Дополнительно настраивать на втором узле NLB не нужно

Указываем IP второй ноды и затем выбираем интерфейс для NLB

Если интерфейс для NLB на второй ноде был предварительно настроен то можно смело жать Next

Можно определить какие протоколы и порты будут затронуты кластеризацией на узле 2

После завершения получаем такую картину

Смотрим IP конфигурацию второй ноды после добавление в кластер

Как видим, виртуальный MAC-адрес NLB-интерфейса второй ноды идентичен с виртуальным MAC-адресом NLB-интерфейса первой ноды (это значит что все сетевые пакеты, адресованные NLB-кластеру, примут абсолютно все узлы. А уж потом между собой разберутся какой конкретно узел обработает клиентский запрос).

4. Добавляем записи в DNS

Я добавил имена каждой из нод в DNS, связав их с соответствующим IP-адресом второго (не NLB интерфейса)