MPIO (Multi-Path Input/Output) в системах хранения

Жесткие требования к отказоустойчивости, предъявляемые к современным системам хранения, заставляют производителей дублировать все важные узлы своих систем. Воплощением этих тенденций стала система хранения данных ETegro Fastor FS200 G2. Данная СХД (SAN) имеет два съемных модуля, каждый из которых содержит дисковый контроллер, сетевой и консольный интерфейсы, разъемы подключения SAS и Fiber Channel (фото слева). Оба модуля независимы и поддерживают горячую замену. Два автономных блока питания можно подключить к разным источникам. Блоки охлаждения также продублированы и сделаны съемными. СХД оборудована также системой резервного питания кэш памяти в случае отключения энергии. Повышение отказоустойчивости средствами удобного ПО с графическим интерфейсом и консолью тоже не оставлено без внимания — помимо возможностей по повышению надежности массивов, таких как фоновое восстановление массива, глобальный/локальный диск замены, реализована поддержка снимков (snapshot) и LVM.

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

Multi-Path Input Output — технология, позволяющая соединять устройства хранения и серверы, используя несколько портов или контроллеров, обеспечивая тем самым избыточность подключений. С помощью дополнительных компонентов физических путей (адаптеры, кабели, коммутаторы) создаются логические пути между сервером и хранилищем. При выходе из строя одного или нескольких компонентов, логика MultiPath позволит использовать альтернативный логический путь, сохраняя для приложений доступ к данным.

  Вприведенном на рисунке слева стенде сервер ETegro Hyperion RS130 G3 подключен к системе хранения ETegro Fastor FS200 G2 с помощью оптоволоконных кабелей через коммутаторы QLogic. Как понятно из схемы между сервером и SAN существуют восемь физических путей. 

 

Предположим, что оптимальным путем для данной схемы является путь HBA1→A→E→Ctrl1. В реальности политики MPIO можно настроить так, чтобы использовалось несколько путей одновременно с балансировкой нагрузки. Мы же рассмотрим пример с политикой Failover Only, когда одновременно используется только один путь, без какой либо балансировки.

При сбое «FC-коммутатора 1» физические пути HBA1→A→E→Ctr1, HBA1→A→G→Ctr2, HBA2→B→E→Ctr1 и HBA2→B→G→Ctr2 станут недоступными и MPIO перенаправит активный логический путь по физическому пути HBA1→C→F→Ctr1, HBA1→C→H→Ctr2, HBA2→D→F→Ctr1 или HBA2→D→H→Ctr2, в зависимости от настроек политик.

  Если же к этому произойдет отказ одного из контроллеров системы хранения, например Ctr2, то MPIO задействует оставшиеся физические пути HBA1→C→F→Ctr1 и HBA2→D→F→Ctr1.

И даже после отказа одного из адаптеров сервера описанная система будет функционировать.
MPIO в Windows Server 2008 R2















MPIO в Windows Server 2008 R2

В операционной системе Windows Server 2008 R2 предусмотрена встроенная поддержка многопутевого ввода-вывода. Технология Microsoft MPIO обеспечивает высокую доступность подключения серверов посредством создания нескольких сеансов или подключений к массиву хранилища, поддерживая подключения сетевых хранилищ данных с использованием iSCSI, оптоволоконных каналов (Fiber Channel) и хранилищ SAS.


Установка

  Установка MPIO в системе Windows Server 2008 R2 производится с помощью оснастки Компоненты (Features) в меню Управление сервером (Server Manager).

В области Компоненты (Features) щелкнуть Добавить компоненты (Add features) и на странице Выбор компонентов (Add Features Wizard) отметить Многопутевой ввод-вывод (Multipath I/O). Подтвердить выбранные элементы и установить их.

 
Альтернативным способом является установка Multipath I/O с помощью командной строки. Для этого следует запустить консоль Windows PowerShell и выполнить следующие команды:
Import-Module Servermanager
Add-WindowsFeature Multipath-IO

После установки Multipath I/O можно открыть диалоговое окно Свойства MPIO из панели управления или с помощью элемента MPIO в компоненте Администрирование, расположенном в меню Пуск.








Настройка MPIO

В число компонентов MPIO входит специальный модуль для устройств (DSM), который позволяет задавать политики балансировки нагрузки. Особенности настройки модуля зависят от модели контроллера массива хранения и могут предоставляться в качестве отдельного модуля DSM соответствующими производителями оборудования.

 Сторонние модули DSM следует устанавливать с помощью вкладки Установка DSM (DSM Install) в окне Свойства MPIO (MPIO Properties). Множество массивов хранения, совместимых с Active/Active и SPC3, также могут работать с универсальным модулем DSM MPIO, встроенным в систему. Данный модуль автоматически определяет наличие устройств, для которых имеется несколько путей к массивам хранения. Такие устройства отображаются на вкладке Обнаружение многопутевых устройств (Discover Multi-Paths). Отметив нужное устройство добавляем его нажав Добавить (Add). 

  До того, как мы добавили устройство в MPIO, система рассматривала два наших физических подключения как два разные логические устройства (LUN).

После добавления устройства в MPIO и перезагрузки в Диспетчере дисков мы увидим уже одно устройство.

Добавленное устройство появится в списке MPIO устройств. Если системе не удается самостоятельно обнаружить устройство с множественным подключением, есть возможность добавить его вручную, введя идентификатор продукта и поставщика с помощью кнопки Добавить (Add) на этой вкладке.











Политики MPIO

Для настройки политики балансировки перейти в оснастку Управление дисками (Disk Management) и щелкнув правой кнопкой мыши на области диска выбрать Свойства (Properties).












Управление политикой балансировки расположено на вкладке MPIO и в зависимости от типа вашего оборудования может включать:

Переход на другой ресурс при сбое (Failover). Балансировка нагрузки не осуществляется. Приложение указывает основной путь и набор резервных путей. Основной путь (Active/Optimized) используется для обработки запросов устройства. При сбое основного пути используется один из резервных путей (Active/Unoptimized). Резервные пути должны быть указаны в порядке убывания предпочтения (самый предпочитаемый путь должен быть первым в списке).









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

Циклический перебор (Round Robin). Модуль DSM использует все доступные пути для ввода и вывода с помощью сбалансированного циклического перебора.

Циклический перебор с поднабором путей (Round Robin With Subset). В приложении указывается набор путей, которые будут использоваться при циклическом переборе, а также набор резервных путей. Модуль DSM использует пути из основного пула путей для обработки запросов до тех пор, пока доступен хотя бы один путь. Модуль DSM использует резервный путь (Active/Unoptimized) только при отказе всех основных путей (Active/Optimized) . Резервные пути должны быть указаны в порядке убывания предпочтения (самый предпочитаемый путь должен быть в списке первым). Если один или несколько из основных путей становятся доступными, модуль DSM использует резервные пути в порядке их предпочтения. Например, пусть есть четыре пути: А, Б, В и Г. Основными путями являются А, Б и В, а Г является резервным путем. Модуль DSM выбирает один из путей (А, Б или В) путем циклического перебора, пока хотя бы один из них доступен. В случае отказа всех трех путей модуль DSM будет использовать путь Г (резервный путь). Если пути А, Б или В вновь станут доступными, то модуль DSM прекратит использование пути Г и переключится на доступные пути (A, Б или В) (Рисунок 1).

Динамическая наименьшая глубина очереди (Least Queue Depht). Модуль DSM направляет ввод и вывод по пути с наименьшим количеством запросов, ожидающих выполнения.

Взвешенный путь (Weighted Paths). Приложение назначает каждому пути вес, который показывает относительный приоритет данного пути. Чем больше значение Weight, тем ниже приоритет. Модуль DSM из доступных путей выбирает путь с наименьшим весом.















По умолчанию для контроллеров Active/Active система Windows Server 2008 R2 выбирает режим Циклический перебор (Round Robin), а для контроллеров ALUA SPC-3 выбирается режим Переход на другой ресурс при сбое (Failover).

На вкладке MPIO (рисунок выше) также доступна информация по текущим путям. Попав с помощью кнопки Edit в меню MPIO Path Details можно просмотреть статистику нужного подключения или в случае использования, например, политики Round Robin With Subset назначить данный путь для балансировки (Active/Optimized) или в качестве резервного (Active/Unoptimized).

Управлять настройками MPIO можно также из командной строки утилитой mpclaim.exe. С ее помощью можно включать и выключать MPIO для нужного устройства, назначать политики распределения нагрузки (Load Balance policy), просматривать информацию об имеющихся устройствах, поддерживающих MPIO. Например, команда mpclaim –s –d показывает информацию o MPIO дисках, которые есть в системе, а команда mpclaim –s –d 1 выводит детальную информацию о первом MPIO диске.


Источник:  http://www.etegro.ru

Loopback processing of Group Policy

As we know group policy has two main configurations, user and computer. Accordingly, the computer policy is applied to the computer despite of the logged user and the user configuration is applied to the user despite of the computer he is logged on.

For example we have a Domain, this Domain has two different organizational units (OU) Green and Red, Green OU contains a Computer account and Red OU contains User account. The Green policy, which has settings “Computer Configuration 2” and “User Configuration 2” is applied to the OU with the computer account. The Red policy, which has settings “Computer Configuration 1” and “User Configuration 1”, is applied to the OU with the User account. If you have a look at the picture below it will become clearer.

If Loopback processing of Group Policy is not enabled and our User logs on to our Computer, the following is true:

As we can see from the picture, the User gets Computer Configuration 2 and User Configuration 1. This is absolutely standard situation, where policies are applied according to the belonging to the OU. User belongs to the Red OU, he gets the Red User configuration 1 accordingly.

Now let’s enable the Loopback processing of Group Policy for the Green OU. In this case if the User logs on to the Computer, the policies applied in the following way:

As we can see, now the User is getting User Configuration 2 despite of the fact that he belongs to the Red OU. So, what has happened in this scenario, the User Configuration 1 was replaced with the User Configuration 2, i.e. with the configuration applied to the Computer account.

 As you have probably noticed, the picture above says “Loopback in replace mode”. I have to mention that the Loopback processing of Group Policy has two different modes, Replace and Merge. It is obvious that Replace mode replaces User Configuration with the one applied to the Computer, whereas Merge mode merges two User Configurations.

In Merge mode, if there is a conflict, for example two policies provide different values for the same configuration setting, the Computer’s policy has more privilege. For example in our scenario, in case of the conflict the User Configuration 2 would be enforced.

In the real work environment Loopback processing of Group Policy is usually used on Terminal Servers. For example you have users with enabled folder redirection settings, but you do not want these folder redirection to work when the users log on to the Terminal Server, in this case we enable Loopback processing of Group Policy in the Policy linked to the Terminal Server’s Computer account and do not enable the folder redirection settings. In this case, once the User logged on to the Terminal Server his folder redirection policy will not be applied.

How to get rid of Windows.old folder after the upgrade to Windows Server 2012?

After the server is upgraded to Windows Server 2012 there is an useless folder in the root of C:\, titled Windows.old. This folder is BIG: ranges from 10 GB to 25 GB in size, depending on the role of the upgraded server.

So it’s better to remove that folder, but how? In Windows Server 2008 R2 you had the Disk Cleanup button located in the Properties screen of every logical disk shown in the Explorer. But in Windows Server 2012 this button isn’t present any more by default:

The folder Windows.old is locked by default so it takes some time to gain permissions on ALL those folders found in the main folder Windows.old. So that’s not the way to go.

Gladly in Windows Server 2012 there is a better way: Just get the earlier mentioned button back. How?
1. Start PowerShell on the related Windows Server 2012 machine;
2. Enter: Install-WindowsFeature Desktop-Experience and hit <ENTER>;
3. It will run for some minutes and report when ready;
4. Reboot the server, the feature will be installed and initialized while rebooting. This takes some minutes as well;
5. After the server is fully functional again the button Disk Cleanup is back again:

6. Hit the button and after the scan it will show you next window;

7. Hit next button - "Clean up system files";

8. Hit the button and after the scan it will show you the option to remove the Windows.old folder;

9. OK > Delete Files;

10. It will run for some minutes;

11.After a while the Windows.old folder is deleted.
When required, the PS-cmdlet Remove-WindowsFeature Desktop-Experience will remove this feature again from your server.

Проблема с WMI на контроллере домена - Windows Server 2012 Standard

После миграции контроллеров домена, а соовтетственно и повышения уровней DFL и FFL, столкнулся с проблемой на 1 контроллере домена.
Проблема заключалась в следующем:
1. В root\cimv2 отсутствовала добрая половина классов
2. Не работал RSOP.msс - The client-side extension could not log RSoP data because it failed with error code '0x8004401e <unknown-message-text , а так же были проблемы с применением групповых политик -

Решилось перерегистрацией .dll и перекомпилированием .mofs в директории wbem и последующим перестроением WMI репозитория.

a. Re-register all of the dlls and recompile the .mofs in the wbem folder and re-registering WMI Service and Provider. You can use the following script by saving to txt file then renaming to .bat and running from command prompt with admin right and changing focus to following directory: C:\Windows\System32\Wbem.

sc config winmgmt start= disabled
net stop winmgmt /y
%systemdrive%
cd %windir%\system32\wbem
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
wmiprvse /regserver
winmgmt /regserver
sc config winmgmt start= auto
net start winmgmt
for /f %%s in ('dir /s /b *.mof *.mfl') do mofcomp %%s

  b. Reboot the machine and test WMI.

Next, check the repository for consistencies:

 winmgmt /verifyrepository

If repository is found to be inconsistent:
For Vista and newer, run from elevated command prompt:

Winmgmt /salvagerepository

Note this command will take the content of the inconsistent repository and merge it into the rebuilt repository if it is readable.
If the above doesn’t work, then run:

Winmgmt /resetrepository (This will reset repository to the initial state when the OS was first installed)

For Windows XP and Windows Server 2003, there are no built in switches to rebuild the Repository, so you must do it manually.

Warning: Rebuilding the WMI repository has resulted in some 3rd party products not working until their setup is re-run & their MOF re-added back to the repository.

If /salvagerepository or /resetrepository does not resolve the issue, then manually rebuild repository:

1. Change startup type to Window Management Instrumentation (WMI) Service to disabled
2. Stop the WMI Service; you may need to stop IP Helper Service first or other dependent services before it allows you to stop WMI Service
3. Rename the repository folder: C:\WINDOWS\system32\wbem\Repository to Repository.old
4. Open a CMD Prompt with elevated privileges
5. CD windows\system32\wbem
6. for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
7. Set the WMI Service type back to Automatic and start WMI Service
8. cd /d c:\ ((go to the root of the c drive, this is important))
9. for /f %%s in ('dir /s /b *.mof *.mfl') do mofcomp %%s
10. Reboot the server

Finally, install latest hotfixes for WMI as they can help prevent issue from recurring. If you continue to have recurring WMI repository corruption issues on same machine, please engage a Microsoft Support Engineer for further troubleshooting and assistance.