ALUA, или Asymmetric Logical Unit Access это протокол внутри спецификаций SCSI-2 и SCSI-3, позволяющий правильно организовывать доступ к данным, доступным по различным путям с различными характеристиками доступа. Для его использования, понимать ALUA должны все участники, как система хранения, так и OS хоста.
С ситуацией асимметричного доступа часто сталкиваются при организации подключения двумя путями через два различных контроллера системы хранения. Например, у нас есть LUN, находящийся на дисках, которые обслуживаются определенным контроллером системы хранения, такой контроллер называется для этих дисков “owner”. Однако, для обеспечния отказоустойчивости, эти диски, и данные с них, могут быть доступны через второй контроллер системы хранения, но по неоптимальному по характеристикам доступа пути.
Несмотря на то, что данные с дисков доступны обоим контроллерам, все операции с “владеемыми” дисками, для обеспечения целостности данных, пока он “жив”, должен совершать именно контроллер-владелец соответствующих дисков.
Рассмотрим подробнее на рисунке.
Вы видите, что хост, подключающийся к LUN A по пути A, получает данные наиболее “прямым” образом. А хост, подключающийся через второй контроллер, по пути B, хотя и тоже может видеть данные LUN, но получает его данные неоптимально. Его запрос на данные проходит через второй контроллер (FAS B), кластерный интерконнект между контроллерами, попадает на первый контроллер, обрабатывается им, и отправляется к его “owned” дискам. Данные пойдут в адрес запросившего хоста в обратном порядке, с дисков к контроллеру-owner, затем по интерконнекту, на второй контроллер, и через его порты к запросившему хосту. В результате загружаются работой оба контроллера вместо одного, данные загромождают интерконнект, и производительность снижается.
В этом случае вы сможете наблюдать в логах сообщение вида:
Это сообщение как раз и указывает на то, что данные получаются хостом через порты “чужого” контроллера, по неоптимальному пути.
Для того, чтобы автоматически разруливать такие ситуации, и организовывать подключение в нормальном режиме, когда оба пути к обоим работающим контроллерам активны, но один из них более предпочтителен, чем другой, и используется ALUA.
Из операционных систем его поддерживают свежие Linux, MS Windows 2008 со своим DSM и VMware ESX4 (vSphere). Поддержка ALUA есть и в Data ONTAP от 7.3.1.
Рассмотрим, как включить использование ALUA в vSphere.
Убедитесь, что на системе хранения вы используете версию Data ONTAP от 7.3.1 и выше.
FAS1> version
NetApp Release 7.3.1.1: Mon Apr 20 22:58:46 PDT 2009
Включите флаг ALUA для igroups ESX на каждом из контроллеров системы хранения
FAS1> igroup show -v vmesx_b
vmesx_b (FCP):
OS Type: vmware
Member: 21:00:00:1b:32:10:27:3d (logged in on: vtic, 0b)
Member: 21:01:00:1b:32:30:27:3d (logged in on: vtic, 0a)
ALUA: No
FAS1> igroup set vmesx_b alua yes
FAS1> igroup show -v vmesx_b
vmesx_b (FCP):
OS Type: vmware
Member: 21:00:00:1b:32:10:27:3d (logged in on: vtic, 0b)
Member: 21:01:00:1b:32:30:27:3d (logged in on: vtic, 0a)
ALUA: Yes
С помощью VMotion переместите все VM с данного хоста ESX на другие хосты кластера и перезагрузите данный сервер ESX.
После перезагрузки значение SATP (Storage Array Type) изменится на VMW_SATP_ALUA, а PSP (Path Selection Policy) на VMW_PSP_MRU. Вам нужно изменить PSP с VMW_PSP_MRU на VMW_PSP_RR. Сделать это можно двумя способами.
1. С помощью NetApp ESX Host Utilities Kit 5.1
#/opt/netapp/santools/config_mpath –m -a CtlrA:username:password -a CtlrB:username:password
После изменений вы получите соответствующее собщение и предложение перезагрузить ESX
2. Вручную
# esxcli nmp satp setdefaultpsp –satp VMW_SATP_ALUA –psp VMW_PSP_RR
Перезагрузка сервера ESX
Проверьте получившеся настройки
#esxcli nmp device
naa.60a9800050334b356b4a51312f417541
Device Display Name: NETAPP Fibre Channel Disk (naa.60a9800050334b356b4a51312f417541)
Storage Array Type: VMW_SATP_ALUA
Storage Array Type Device Config: {implicit_support=on;explicit_support=off;explicit_allow=on;alua_followover=on;{TPG_id=2,TPG_state=AO}{TPG_id=3,TPG_state=ANO}}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=3: NumIOsPending=0,numBytesPending=0}
Working Paths: vmhba2:C0:T2:L1, vmhba1:C0:T2:L1
Теперь хост, подключенный портами в разные контроллеры системы хранения, будет направлять данные только по оптимальному для доступа к данному LUN пути, автоматически избегая неоптимального интерфейса.
![1269282124-clip-89kb[1]](http://pics.aboutnetapp.ru//1269282124clip89kb1.png "1269282124-clip-89kb[1]")
