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.

SCOM 2012: about the RMS emulator

Operations Manager (OpsMgr) is the infrastructure monitoring engine in System Center, one of eight management products in the System Center 2012 suite. Visually, OpsMgr is the least changed member of the new System Center 2012 family, with a user interface (UI) little different from the current release, Operations Manager 2007 R2. Under the hood, there are a few significant changes in the new release, in particular how OpsMgr management servers are deployed and maintained. The most significant is perhaps the “removal of the RMS” in System Center 2012 Operations Manager.


Say goodbye to the RMS Cluster:

In previous releases of OpsMgr, there was one key management server called the Root Management Server (RMS). The RMS services could only be made highly available by using Failover Clustering technology. The requirement to field a cluster for the RMS added cost and complexity to larger-scale and highly available OpsMgr deployments. (Not to mention wasted server capacity on the standby node of the RMS cluster.) Additionally, the RMS and/or RMS cluster constituted a single point of failure for the management group.

The architectural bottlenecks and weaknesses of the RMS are substantially addressed in the System Center 2012 Operations Manager release. OpsMgr will now utilize a pool of co-equal management servers for almost all functions previously performed by only the RMS. However, one management server in the pool is still flagged for the RMS emulator (RMSE) role and some management pack functions may still be single-threaded through the RMSE. Which functions — that will depend on the RMSE role — vary according to the application management packs imported to your management group.


What the RMS emulator does:

It’s important to understand what the RMS emulator does, so that you can architect your System Center 2012 Operations Manager management group correctly. In summary, the RMSE runs management pack functions specifically targeted to the Root Management Server class. These may be classified as “legacy” management packs, because newer management packs will not target the RMS class. In order to not break existing management packs that target the RMS specifically, the RMS emulator class and role were created in System Center 2012 OpsMgr.

Although only a few management packs do target the RMS class directly today, in any particular environment, business critical management packs from other Microsoft teams and third-party vendors could be in the “legacy” category, and thereby have a dependence on the OpsMgr management server running the RMSE role. To see which discoveries, monitors, rules and tasks target the RMS class, filter on the text “root management server” in management pack object views in the Authoring space of the OpsMgr 2007 R2 console. Importing the same management packs into System Center 2012 OpsMgr will target those management pack objects to the RMS emulator class.

Figure A shows that even a System Center 2012 OpsMgr management group running current management packs may have some objects, such as discoveries for Hyper-V guest computers and Active Directory (AD) topology, targeted to the RMSE class. In the event of failure and/or permanent loss of the RMSE, management pack functions targeting the RMSE will stop working until you promote a surviving management server to RMSE, which is fast and simple to do using PowerShell. This assumes your management group has at least two management servers, the minimum number necessary to have fault tolerance in the RMSE role.

To assess the importance of the RMSE role to a prospective System Center 2012 OpsMgr deployment: identify and evaluate the management pack objects in your current OpsMgr 2007 R2 environment that are targeted to the Root Management Server class. If the product teams or vendors involved do not release updated management packs, the same RMS targeting will occur in System Center 2012 OpsMgr. Alternatively, in a lab or demo deployment of System Center 2012 OpsMgr, import the latest version of all management packs you intend to run in production on the new version of OpsMgr, and evaluate the management pack objects targeted to the Root Management Server Emulator class.


Recovery from disaster:

A large benefit of System Center 2012 OpsMgr is freedom from having to deploy cluster services to achieve a highly available RMS. In the event you lose the management server running the RMS emulator role, expect to follow disaster recovery (DR) steps similar to these:

1. Promote another management server to the RMS emulator role using PowerShell. Here are the two PowerShell commands to be run to designate a management server as the RMSE:
   $MS = get-SCOMManagementServer -Name <FQDN of Management Server>
   set-SCOMRMSEmulator $MS
2. Install a new Windows Server operating system on a computer with the same name and IP address as the original RMS emulator.
3. Delete the failed management server name from the Management Servers list in the OpsMgr console Administration space. (You can’t join the rebuilt management server to the management group without performing this step.)
4. Install the OpsMgr management server role on the rebuilt computer, following the procedure to install an additional management server to the management group.
5. Promote the original RMS emulator back into that role using PowerShell as in step 1.

Acknowledgements, to learn more:

Rob Kuehfus @ Microsoft: http://blogs.technet.com/b/momteam/archive/2011/08/22/topology-changes-in-system-center-2012-operations-manager-overview.aspx

Cameron Fuller @ System Center Central: http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/91085/Default.aspx">

SCOM Discovery Wizard Does Not Work.

Если после миграции с SCOM2007 на SCOM2012 вы с удивлением обнаруживаете, что любое обнаружение устройств неизбежно заканчивается зависанием мастера, то:

1. - Open SQL Server Management Studio

- Select the right instance and the OpsMgr database

- Start a new query on the OpsMgr database:

SELECT is_broker_enabled FROM sys.databases WHERE name = 'OperationsManager'

- Value = 0 :SQL Broker is disabled. Goto Step 2.

- Value= 1 : SQL Broker is enabled. All is OK.

2. - Open SQL Server Management Studio

- Select the right instance and the OpsMgr database

- Start a new query on the OpsMgr database:

ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE

- Click Execute

- Start this query on the OpsMgr database:

ALTER DATABASE OperationsManager SET ENABLE_BROKER

- Click Execute

- Close SQL Server Management Studio.

Note: Closing SQL Server Management Studio closes the connection to the database in single user mode. Most of the times one has to stop all SCOM related services on the RMS since these services have running connections to this database. Without stopping them one won't be able to run the next query.

3. - Open SQL Server Management Studio

- Select the right instance and the OpsMgr database

- Start a new query on the OpsMgr database:

ALTER DATABASE OperationsManager SET MULTI_USER

- Click Execute.

One management product to rule them all

ConfigMgr 2012 SP1 will do management on the following OSEs:

Client devices:

• Windows XP SP3, Windows Vista SP2,
• Windows 7 (SP1), Windows 8
• Windows To Go

Server devices:

• Windows Server 2003 SP2, Windows Server 2003 R2 SP2
• Windows Server 2008 SP2, Windows Server 2008 R2 (SP1)
• Windows Server 2012

Thin Clients based on Windows XP SP3:

• Windows Embedded Standard 2009
• Windows XP Embedded SP3
• Windows Fundamentals for Legacy PCs (WinFLP)
• Windows Embedded POSReady 2009
• WEPOS 1.1 with SP3

Thin Clients based on Windows 7:

• Windows Embedded Standard 7 with SP1
• Windows Embedded POSReady 7
• Windows Thin PC (SA benefit)

MAC Computers:

• Mac OS X 10.6 (Snow Leopard), Mac OS X 10.7 (Lion)
• Linux and UNIX Servers:
• AIX version 5.3, 6.1, 7.1
• HP-UX version 11iv2, 11iv3
• Red Hat Enterprise Linux (RHEL) version 4, 5, 6
• Solaris version 9, 10, 11
• SUSE Linux Enterprise Server (SLES) version 9, 10 SP1, 11

Mobile devices (Depth management):

• Windows Mobile 6.1, Windows Mobile 6.5 (phones)
• Nokia Symbian Belle (phones)
• EAS connected Mobile devices (Light management):
• Windows Phone 7
• Android, iOS (phones and tablets)
• Windows Intune integration (Depth management):
• Windows Phone 7, Windows Phone 8
• Windows Runtime (RT) tablets
• Android, iOS (phones and tablets)