Disclaimer: DataCore
SANsymphony-V supported Solaris 11 derzeit nicht! Darüber hinaus ist die Nutzung von iSCSI mit Solaris und
DataCore SANsymphony-V ebenfalls nicht supported. Die Umgebung ist also unsupported und nichts für den Produktionsbetrieb. Für weitergehende Informationen lohnt sich ein Blick in das Technical Bulletin #3 von DataCore.
Im Rahmen eines kleinen PoC musste ich ein paar Virtual Disks an eine Solaris 11 Maschine hängen. Keine große Sache. Für die iSCSI Anbindung habe ich eine dedizierte NIC in der VM genutzt. An diese NIC habe ich zwei IPs gebunden, um die beiden Fronend Ports meiner Storage Server zu erreichen.
Im Rahmen eines kleinen PoC musste ich ein paar Virtual Disks an eine Solaris 11 Maschine hängen. Keine große Sache. Für die iSCSI Anbindung habe ich eine dedizierte NIC in der VM genutzt. An diese NIC habe ich zwei IPs gebunden, um die beiden Fronend Ports meiner Storage Server zu erreichen.
root@tstclu01:~# ipadm create-ip net1 root@tstclu01:~# ipadm create-addr -T static -a 10.1.1.150/24 net1/iscsi1 root@tstclu01:~# ipadm create-addr -T static -a 10.1.2.150/24 net1/iscsi2Bei mehrern NICs würde man einfach die IPs an unterschiedliche Interfaces binden. Nach einer kurzen Prüfung der Verbindung zu den Frontend Ports, habe ich die Discovery konfiguriert.
root@tstclu01:~# iscsiadm add discovery-address 10.1.1.20 10.1.2.20 10.1.1.21 10.1.2.21 root@tstclu01:~# iscsi adml list discovery-address Discovery Address: 10.1.1.20:3260 Discovery Address: 10.1.2.20:3260 Discovery Address: 10.1.1.21:3260 Discovery Address: 10.1.2.21:3260Die DataCore Storage Server haben jeweils zwei NICs als Frontend Ports, insgesamt stehen also vier Pfade zu jeder Virtual Disk zur Verfügung. Die Nutzung von Send Targets (Dynamic Discovery) vereinfacht das Leben ungemein. Der iSCSI Initiator sucht dabei eine IP, oder eine Liste von IPs, nach Targets ab.
root@tstclu01:~# iscsiadm modify discovery -t enableAnschließend habe ich den Host unter DataCore SANsymphony-V registriert. Da ich nur einen Initiator zur Auswahl hatte, war die Zuordnung Intiator <> Server kein Problem. Sollte man in dem Dialog verschiedene Initiator zur Auswahl haben, so kann man den IQN unter Solaris wie folgt prüfen:
root@tstclu01:~# iscsiadm list initiator-node Initiator node name: iqn.1986-03.com.sun:01:e00000000000.51bf6466 Initiator node alias: tstclu01 Login Parameters (Default/Configured): Header Digest: NONE/- Data Digest: NONE/- Max Connections: 65535/- Authentication Type: NONE RADIUS Server: NONE RADIUS Access: disabled Tunable Parameters (Default/Configured): Session Login Response Time: 60/- Maximum Connection Retry Time: 180/- Login Retry Time Interval: 60/- Configured Sessions: 1Nun noch schnell die Targets anbinden...
root@tstclu01:~# iscsiadm add static-config iqn.2000-08.com.datacore:tstssv01-fe2,10.1.2.20:3260 root@tstclu01:~# iscsiadm add static-config iqn.2000-08.com.datacore:tstssv02-fe1,10.1.1.21:3260 root@tstclu01:~# iscsiadm add static-config iqn.2000-08.com.datacore:tstssv02-fe1,10.1.1.20:3260 root@tstclu01:~# iscsiadm add static-config iqn.2000-08.com.datacore:tstssv02-fe2,10.1.2.21:3260... und Virtual Disks präsentieren. Anschließend nach Disks suchen und das Ergebnis bewundern:
root@tstclu01:~# devfsadm -i iscsi root@tstclu01:~# format Searching for disks...done
AVAILABLE DISK SELECTIONS: 0. c0t60030D9022F9E3015397A702F298A282d0 <DataCore-Virtual Disk-DCS cyl 1303 alt 2 hd 255 sec 63> /scsi_vhci/disk@g60030d9022f9e3015397a702f298a282 1. c8t0d0 <VMware-Virtual disk-1.0-20.00GB> /pci@0,0/pci15ad,1976@10/sd@0,0 Specify disk (enter its number): ^C root@tstclu01:~# zpool create test c0t60030D9022F9E3015397A702F298A282d0 root@tstclu01:~# zpool status test pool: test state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 c0t60030D9022F9E3015397A702F298A282d0 ONLINE 0 0 0 errors: No known data errors
Damit kann man arbeiten. Multipathing scheint auch zu funktionieren.
Aktiviert man den Storage Server wieder, sind nach der Log Recovery (und ggfl. devfsadm -i iscsi) auch alle vier Pfade wieder verfügbar. Aber es ist ja nur ein Test im Rahmen enes PoC gewesen... ;)
root@tstclu01:~# mpathadm show lu /dev/rdsk/c0t60030D9022F9E3015397A702F298A282d0s2 Logical Unit: /dev/rdsk/c0t60030D9022F9E3015397A702F298A282d0s2 mpath-support: libmpscsi_vhci.so Vendor: DataCore Product: Virtual Disk Revision: DCS Name Type: unknown type Name: 60030d9022f9e3015397a702f298a282 Asymmetric: yes Current Load Balance: round-robin Logical Unit Group ID: NA Auto Failback: on Auto Probing: NA Paths: Initiator Port Name: iqn.1986-03.com.sun:01:ffffffffffff.51c05f61,4000002a00ff Target Port Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe2,1 Override Path: NA Path State: OK Disabled: no Initiator Port Name: iqn.1986-03.com.sun:01:ffffffffffff.51c05f61,4000002a00ff Target Port Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv01-fe1,1 Override Path: NA Path State: OK Disabled: no Initiator Port Name: iqn.1986-03.com.sun:01:ffffffffffff.51c05f61,4000002a00ff Target Port Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv01-fe2,1 Override Path: NA Path State: OK Disabled: no
Initiator Port Name: iqn.1986-03.com.sun:01:ffffffffffff.51c05f61,4000002a00ff Target Port Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe1,1 Override Path: NA Path State: OK Disabled: no Target Port Groups: ID: 2 Explicit Failover: no Access State: active optimized Target Ports: Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe2,1 Relative ID: 2055 Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe1,1 Relative ID: 2052 ID: 1 Explicit Failover: no Access State: active optimized Target Ports: Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv01-fe1,1 Relative ID: 1031 Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv01-fe2,1 Relative ID: 1030Leider ist das mit dem Multipathing nicht ganz sauber. Simuliert man einen Ausfall, z.B. durch das stoppen einen DataCore Storage Servers, dann ruckelt es erstmal gewaltig. So hängt z.B. ein "zpool status" eine ganze Weile. Ansonsten funktioniert die Verbindung. Das Schreiben auf das testweise angelegte Dateisystem klappt auch mit nur zwei Pfaden.
root@tstclu01:/test# mpathadm show lu /dev/rdsk/c0t60030D9046190D051C3A67447DE39615d0s2 Logical Unit: /dev/rdsk/c0t60030D9046190D051C3A67447DE39615d0s2 mpath-support: libmpscsi_vhci.so Vendor: DataCore Product: Virtual Disk Revision: DCS Name Type: unknown type Name: 60030d9046190d051c3a67447de39615 Asymmetric: yes Current Load Balance: round-robin Logical Unit Group ID: NA Auto Failback: on Auto Probing: NA Paths: Initiator Port Name: iqn.1986-03.com.sun:01:ffffffffffff.51c06309,4000002a00ff Target Port Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe2,1 Override Path: NA Path State: OK Disabled: no Initiator Port Name: iqn.1986-03.com.sun:01:ffffffffffff.51c06309,4000002a00ff Target Port Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe1,1 Override Path: NA Path State: OK Disabled: no Target Port Groups: ID: 1 Explicit Failover: no Access State: unavailable Target Ports: Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv01-fe2,1 Relative ID: 1030 Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv01-fe1,1 Relative ID: 1031 ID: 2 Explicit Failover: no Access State: active optimized Target Ports: Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe2,1 Relative ID: 2055 Name: 4000002a0000,iqn.2000-08.com.datacore:tstssv02-fe1,1 Relative ID: 2052
Aktiviert man den Storage Server wieder, sind nach der Log Recovery (und ggfl. devfsadm -i iscsi) auch alle vier Pfade wieder verfügbar. Aber es ist ja nur ein Test im Rahmen enes PoC gewesen... ;)