» Solaris COMSTAR и SCSI Target Mode Framework

ivanovsn

а скажите, чем с backplane от Norco RPC 4220 на мамку вы винты цепляли? куча sata кабелей на дополнительный контроллер (20 штук, или мамка их все 20 умеет?) или все-таки 1 какой-нибудь?

спасибо.

rpc-4220 имеет sff-8087 разъем.
подключается таким кабелем http://www.ipcdirect.net/servlet/Detail?no=215
не то чтобы сильно, но путаницу снижает.
там кстати вообще интересные девайсики есть. но можно найти дешевле.
бакплейны весьма хлипкие на вид. есть информация что сейчас стали выпускать бакплейн новой ревизии. выгладит надежнее.
с октября будут продавать панель на 3 120мм вентилятора, сейчас идет 4*80мм, вентиляторы стоят FFB0812SHE. 55 db текущяя панель продумана плохо: сосет воздух из корпуса вместо винтов, по пути наименьшего сопротивления.
стоит 3 контроллера aoc-sat2-mv8. правда умные люди подскзали что можно пробить LSI SATA контроллеры на алибабе, стоят они там в районе $50, но уже поздно было.
вообще PCI-X стоит существенно дешевле PCI-E. материнские платы, опять-таки, с 4-5 разъемами PCI-X можно легко найти например в вмваре у меня стоит tyan k8hm: 3*PCI-X, 2*PCI-Ex8 отдал за нее 30 баксов )

Цитата:

умные люди подскзали что можно пробить LSI SATA контроллеры на алибабе

ivanovsn
мозг себе вынес
а этого нет в китайских интернет магазинах ?

скоро год, а воз и ныне тем ?

sas target есть в соляре ?

Плиз. Хелп.
Прикупил сей девайс (brocade 200e) на ибэе, надпись была что Used, but working condition
Включил пишет в консоли не может инициализировать диски АТА
Разобрал нет Флешки внутри с операционкой, если у кого есть возможность снять образ с флешки плиз помогите. В долгу не останусь, нужно для образовательных целей.

Скрипты для управления маппингом лунов в COMSTAR
https://github.com/robinsmidsrod/comstar-soho-helper

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

https://github.com/robinsmidsrod/comstar-soho-helper/blob/master/README.md

Вот ещё полезная техника, позволяющая давать лунам осмысленные guid-ы (дайджесты строк) в stmfadm :
https://blogs.oracle.com/jayd/entry/iscsi_failover_with_comstar

Только я бы переваривал имена zvol-ов, а не таргетов: в этом случае имена лунов вида naa..., соответствующие определённому zvol, всегда будут одинаковыми - и нежная крыша вцентра будет пощажена.

В результате lu можно смело создавать-удалять динамически, модифицированными командами iscsi_volume_connect и iscsi_volume_disconnect из предыдущей ссылки.

(не тестировал, но в ближайшее время собираюсь и отпишусь)

Чё делают скрипты из позапрошлого поста?

iscsi_target_create volname

Создаётся таргет-портал-группа связанная с взятым из конфига именем сетевого интерфейса.
Создаётся zvol, расположенный по взятому из конфига пути, с именем volname

Для этого zvol cоздаётся lu c автогенерированным именем (guid для использования в формате naa)
(1:1 к volname поддерживается средствами STMF, в дальнейшем остальные скрипты извлекают это имя по ключу volname
lu - это продукт sbd (scsi block device) провайдера, stmf поддерживает разнообразных провайдеров, но в дистрибутиве соляры и деривативов идёт только этот; в интернете есть несколько реализаций virtual type и cdrom провайдеров, для опенсоляры когда-то сделали sas провайдера и драйвер mtp_target).

Создаётся таргет с взятым из конфига префиксом iqn... и именем volname
Создаётся таргет-группа c именем volname, к ней добавлятся только что созданный таргет.


Все взаимосвязи 1:1:1:1 (недаром скрипты называются soho-helper). На первый взгляд это неудобно, потому что противоречит например идеологии нексентовской VMDC и бестпрактисам нетаппа.

То есть за таргетом оказывается единственный LUN0, а по бестпрактисам за единственным таргетом может быть N лунов. С другой стороны, такое решение исключает перенумерацию лунов на ходу. И нам ничто не мешает соответствующие лунам таргеты цеплять-отцеплять целиком, централизованно из вцентра PowerCLI скриптом. (Или можно и из СХД, через оффлайн/онлайн таргет? TODO: Как к такому отнесутся вцентр и его хосты?)


Можно серьёзно переделать все эти сохо скрипты в сторону бестпрактисов и исключить перенумерацию лунов. Управлять таргетом придётся только этими скриптами, запретив себе в этой части использование GUI и CLI нексенты и прочих управлялок.

Но даже если остановиться на сохо дизайне СХД, именно этот скрипт тоже придётся править, потому что по бестпрактисам и нетаппа, и вмваре виртуалки предпочтительно располагать на разных лунах. За единственной таргет-портал-группой нам надо показать столько таргетов, сколько лунов нужно предъявить инфраструктуре.

Добавлено:

Не добавлять же IP-алиасы по количеству таргетов и таргет-портал-групп? Или попробовать добавлять?
Прошу высказаться.




Добавлено:


http://www.c0t0d0s0.org/archives/6140-Less-known-Solaris-Features-iSCSI-with-COMSTAR.html

Плохая новость.
Гнидогандоидные копирасты патентуют инженерные решения: http://www.freepatentsonline.com/y2010/0076744.html

Хорошее:
Ничего страшного. Софтверные патенты страшны только вендорам, которым хочется торговать коробками с реализацией идеи.
Свободные реализации пока что невозможно ни запретить, ни обложить поборами.

http://broken.net/uncategorized/simple-comstar-iscsi-fcoe-fc-config-view/

http://broken.net/solaris/how-to-backup-and-restore-comstar-stmf-configurations-on-openindiana-and-solaris/



Добавлено:

itadm - управляет конечной точкой iSCSI транспорта

Чтобы клиенты-удаленные инициаторы смогли увидеть свои таргеты (iqn...) за таргет-порталом, должна быть 1) создана содержащая его таргет-портал-группа и 2) затем назначена нужным таргетам.


stmfadm - управляет маппингом лунов в таргет-группы

Маппинг бывает сложный и упрощенный

Сложный маппинг состоит из записей вида
(клиент, сервер, lu guid, LU Number)

Клиент - хостгруппа (группа удаленных инициаторов), которая должны быть создана заранее
Сервер - таргет-группа из таргетов, созданных заранее.

В результате всего этого безобразия один и тот же lu может презентоваться под разными номерами (лунами) разным клиентам.


Упрощенный маппинг не различает клиенты, серверы или и то, и другое.

номер lu (LUN) автогенерируется, но можно задать и в явном виде; по ошибке повторить его для той же пары (клиент, сервер) все равно не выйдет.


sbdadm - управляет провайдером sbd (scsi block device), то есть отображением 1:1 zvol-ов в lu
Почти весь функционал этой утилиты включен в функционал stmfadm

Однако табличная выдача sbdadm list-lu полезна, потому что легко парсится скриптами (пример выше в soho-helper).

http://www.qns.com/xwiki/bin/view/Blog/Solaris+11+iSCSI+target+configuration

Итак, вцентру нужен стабильный сторадж, чтобы луны за таргетами, к которому он цепляется, не перенумеровывались при манипуляциях с СХД. Сама ZFS переносима через zpool export/zpool import. Для стабильности инфраструктуры нехватает такой же переносимости конфигурации COMSTAR.

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

Chaz Chandler
NexentaStor Community Edition iSCSI target/initiator zvol differentiation via command line


Добавлено:

The NexentaStor Community Edition 3 web interface (NMV) does not include advanced iSCSI/zvol management, a feature reserved for their Enterprise Edition. Although you can create zvols and manage iSCSI targets and initiators via the web, all zvols are automatically available via all targets and to all initiators. You can control which initiators can use which targets via authentication, but that would only help you distribute the load on the target address+port – all zvols would still be visible on each target.

As Nexenta is built upon OpenSolaris, one can still manage fine-grained iSCSI and zvol details through the command line.
....



Добавлено:

Процитированное на самом деле неверно, по крайней мере для текущей нексенты. В её вебморде есть страница Mappings, но пользоваться ей неудобно.

Ну и от нексенты отвязаться тоже неплохо, что позволяет сделать скрипт. Приведу его под тегом:

[more]
Since it is laborious to repeat this process multiple times for all the different combinations of host groups, zvols, and target groups necessary, it can be automated somewhat by setting the appropriate shell variables and running this script:

Automation Script for Adding Groups and Modifying Views

Цитата:

#!/usr/bin/bash
#
# iscsiviewmod v0.1: Automation Script for Adding iSCSI Host/Target
# Groups and Modifying View Entries on OpenSolaris
#
# Copyright (C) 2011 Chaz Chandler
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#

if [ $# -lt 6 ]; then
echo "Usage: `/usr/bin/basename $0` targetgroup iscsitarget zvollunname zvollunnumber hostgroup iscsiinitiator0 [iscsiinitiator1 ... ]"
exit 1
fi

# the new target group name to be created
targetgroup=$1
shift

# the iscsi target name to be added
iscsitarget=$1
shift

# the 32-digit name of the zvol (i.e., 600144F07132440000004D28127B0001)
zvollunname=$1
shift

# the LUN number of that zvol (shown by list-view of the above name)
zvollunnumber=$1
shift

# the name of the host group that should be able to see the zvol
hostgroup=$1
shift

# contains the the IQN(s) of the iSCSI initiator(s) to be added to the new host group
iscsiinitiators=$*

stmfadm="/usr/sbin/stmfadm"

# create the tg if it doesn't already exist and add the tgt to it
$stmfadm list-tg $targetgroup 2>/dev/null || $stmfadm create-tg $targetgroup
$stmfadm list-tg -v $targetgroup | /usr/bin/grep "Member: $iscsitarget" || {
$stmfadm offline-target $iscsitarget
$stmfadm add-tg-member -g $targetgroup $iscsitarget
$stmfadm online-target $iscsitarget
}

# create the hg if it doesn't already exist and add given hosts to it
$stmfadm list-hg $hostgroup 2>/dev/null || $stmfadm create-hg $hostgroup
for initiator in $iscsiinitiators; do
$stmfadm add-hg-member -g $hostgroup $initiator
done
$stmfadm remove-view -l $zvolluname 0
$stmfadm add-view -h $hostgroup -t $targetgroup -n $zvollunnumber $zvolluname

echo "Success:"
$stmfadm list-view -l $zvolluname
$stmfadm list-hg -v $hostgroup
$stmfadm list-tg -v $targetgroup

In case it wasn’t clear from the script, the arguments/shell vars should be:

$targetgroup is the new target group name to be created
$iscsitarget the IQN of the iSCSI target to be added to the new target group
$zvolluname is the 32-digit name of the zvol (i.e., 600144F07132440000004D28127B0001)
$zvollunnumber is the LUN number of that zvol (shown by list-view of the above name)
$hostgroup is the name of the host group that should be able to see the zvol
$iscsiinitiators contains the the IQN(s) of the iSCSI initiator(s) to be added to the new host group
The reader is encouraged to modify this script for their specific goals!

To continue the scenario, we want blade2’s BIOS to be able to access the boot zvol, and both ESXi hosts to be able to access both the boot zvol (to continue the boot process one the kernel is loaded from the BIOS’s iSCSI bootloader) and the shared VMFS zvol.

Using iscsiviewmod to create the set of groups and view entries# ./iscsiviewmod blade-boot-targets iqn.2011-01.local.chaznet:bladecenter-esxi-boot 600144F07132440000004D27127C0001 2 blade-boot-blade2 iqn.2011-01.local.chaznet:bladecenter-blade2-bios
Success:
View Entry: 0
Host group : blade-boot-blade2
Target group : blade-boot-targets
LUN : 2
Host Group: blade-boot-blade2
Member: iqn.2011-01.local.chaznet:bladecenter-blade2-bios
Target Group: blade-boot-targets
Member: iqn.2011-01.local.chaznet:bladecenter-esxi-boot
# ./iscsiviewmod blade-vmfs-targets iqn.2011-01.local.chaznet:bladecenter-esxi-vmfs 600144F07132440000004D275F7A0001 0 blade-esxi-hypervisors iqn.2011-01.local.chaznet:bladecenter-blade1-esxi iqn.2011-01.local.chaznet:bladecenter-blade2-esxi
Success:
View Entry: 0
Host group : blade-esxi-hypervisors
Target group : blade-vmfs-targets
LUN : 0
Host Group: blade-esxi-hypervisors
Member: iqn.2011-01.local.chaznet:bladecenter-blade1-esxi
Member: iqn.2011-01.local.chaznet:bladecenter-blade2-esxi
Target Group: blade-vmfs-targets
Member: iqn.2011-01.local.chaznet:bladecenter-esxi-vmfsFinally, we need two more view entries to allow the hypervisors to see their ESXi boot targets:

Adding the last view entry# stmfadm -h blade-esxi-hypervisors -t blade-boot-targets 600144F07132440000004D27127C0001
# stmfadm list-view -l 600144F07132440000004D27127C0001
View Entry: 0
Host group : blade-boot-blade2
Target group : blade-boot-targets
LUN : 2
View Entry: 1
Host group : blade-esxi-hypervisors
Target group : blade-boot-targets
LUN : 2
# stmfadm -h blade-esxi-hypervisors -t blade-boot-targets 600144F07132440000004D28127B0001
# stmfadm list-view -l 600144F07132440000004D28127B0001
View Entry: 0
Host group : blade-boot-blade1
Target group : blade-boot-targets
LUN : 1
View Entry: 1
Host group : blade-esxi-hypervisors
Target group : blade-boot-targets
LUN : 1[/more]

Ошибочной была идея давать логическим единицам осмысленные (digested) guid-ы.

STMF каким-то образом запоминает все предыдущие гуиды (naa....) и не даёт назначить старый гуид. То есть ситуация когда гуид логической единицы меняется после выведения её в офлайн является нормальной, по крайней мере, с точки зрения разработчиков COMSTAR.


А вот с точки зрения вмваре это не так.
Эта тема тесно связана с volume resignaturing.

http://blog.laspina.ca/ubiquitous/understanding-vmfs-volumes
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011387

http://pubs.vmware.com/vsphere-50/index.jsp?topic=/com.vmware.vsphere.storage.doc_50/GUID-8AE88758-20C1-4873-99C7-181EF9ACFA70.html



Цитата:

It’s a VMware generated number – the LVM signature aka the UUID (it’s a long hexadecimal number designed to be unique). The signature itself has little to with anything presented by the storage subsystem (Host LUN ID, SCSI device type), but a change in either will cause a VMFS volume to get resigned (the ESX server says “hey I used to have a LUN with this signature, but it’s parameters were different, so I better resign this”).

http://virtualgeek.typepad.com/virtual_geek/2008/08/a-few-technic-1.html

Солярный ZFS сторадж врёт о себе, что он поддерживает ALUA.

Там внутри всё готово, но реально это заработает только в присутствии отдельного сервиса stmf proxy и юзерспейс-агента управления libstmfproxy Которых нет в бесплатных управлялках, не говоря о бесплатных дистрах.

(навеяно рысканьем по сорцам: ссылок не дам, но советую на эту тему забить)