Gspc Architecture with LUN Management
Auto-generated from the uploaded PDF Gspc_Architecture_with_LUN_Management.pdf. This is an extracted-text rendering for searchability; see the original PDF for exact formatting, diagrams, tables, and images.
Set Of Actions for Detecting and mounting LUN:
Requirement: 2 LUNS were projected to two hosts (gspc-cloud1 and gspc-cloud2) that has to be in high
availability environment. Detail:-
1) Wwid = 36005076300808652a000000000000004 , to be projected to Linux hosts(gspc-cloud1 and
gspc-cloud2) with alias mpathd.
2) Wwid = 36005076300808652a000000000000005 , to be projected to Window_FS VM (running
over /storage) with alias mpathe.
Architecture:
VM1
VM2
SAN
HBA1
HP S\W 1
HBA2 HP S\W2
HOST1= HOST2=
Gspc-cloud1 Gspc-cloud2
NETWORK ARCHITECTURE:
HP S\W 1
eth1
HP S\W 2
eth2
eth0
eth2
E
T E
H T
0 H
3
HOST1= eth3 HOST2=
Gspc-cloud1 Gspc-cloud2
(10.100.10.2) (10.100.10.3)
eth1
SCENARIO:
Firstly, 2 LUNs from SAN are projected at the time of implementation only. One is mounted to both Linux
hosts (i.e, gspc-cloud1 and gspc-cloud2) on “/storage” directory and another is mounted to VM
(Window_FS).
These two host (gspc-cloud1 gspc-cloud2) are running in “High Availability” environment, i.e, in failure
of any one host, services configured in this environment will be migrated to another without any impact.
The services configured in H.A environment is “virtual machine”. This “virtual machine” as-a-service is
running from /storage. Running VM are- Window_FS and Window_RODC.
Apart from this one Virtual_IP is also configured as a service in H.A environment which is “10.100.10.4”.
Now, according to modifications 2 more LUNs have been projected in same way for backup purpose.
Accessing LUN:
1. As LUNs are projected to both hosts from SAN using HBA, multipathing comes into context. Multi-pathing
is used when single storage device (LUN) is connected via various routes. This results in, same storage to be
visible as a separate hard-disks, otherwise.
2. Multi-pathing makes that same single device (LUN) visible and accessible by single name (as settings
configured here).
3. Here, one LUN is projected to “/storage” on both hosts as “mpathb” and second is mounted to VM as
“mpathc”.
4. Also, newly projection are – third LUN projected on directory named “/linux_lun” on both hosts as
“mpathd” and fourth to same VM is “mpathe”.
Challenge :
The name assigned to newly projected 2 LUNs on gspc-cloud1 was reciprocate to names assigned by
gspc-cloud2. This would contradict in fail-over scenario. Thus, signifying that the name assign via
multipath daemon is incorrect.
Solution:
Rectifying Naming convention-
1. Login to gspc-cloud1 (as services running from gspc-cloud2)-- “ssh 10.100.10.2” .
2. Disable all of your multipath devices on your other machines
# service multipathd stop
# multipath -F
3. Copy the /etc/multipath/bindings file from gspc-cloud2 to gspc-cloud1.
4. Re-enable the multipathd daemon.
# service multipathd start
Finally, the 2 LUNs are assigned same name on both hosts. Next is mounting on different machines.
Mounting on VM-
1. LUN with name 'mpathe' has to be mounted on VM, so firstly need to edit xml file with below
command--
“virsh edit Window_FS”
2. Now add below perimeters (after already described virtio disk).
</disk>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source dev='/dev/mapper/mpathe'/>
<target dev='vdd' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
3. Save and exit the file. Copy the xml file to “/storage/KVMCLUSTXML/” .
“cp /etc/libvirt/qemu/Window_FS.xml /storage/KVMCLUSTXML/ ”
4. Now run the command to attach-disk in live environment.
“virsh attach-disk Window_FS /dev/mapper/mpathe vdd --cache none –persistent”
5. Thus, LUN projected as 'mpathe' is permanently mounted to Window_FS VM.
Mounting on Linux Hosts-
1. LUN mapped as 'mpathd' has to be mounted on both hosts with gfs2 file system within same
cluster.
2. For this, we have to add this in existing volume group (i.e, cinder—volumes) for which we have
have initialize it as physical volume. This will be done by below command--
“pvcreate /dev/mapper/mpathd”
3. Extend the volume group.
“vgextend cinder-volumes /dev/mappper/mpathd”
4. Create the new LV of size 400GB.
“lvcreate -L 400G -n lsan1 cinder-volumes”
-L for size of LVM.
-n for name of lvm.
5. Format with gfs2 file-system.
mkfs -t gfs2 -p lock_dlm -t gspc-cloud:new -j 4 /dev/mapper/cinder-volumes-lsan1
-t for file system type
-p for locking protocol
-t for lock table {related to cluster}
-j for number of journals.
6. Create a directory - “mkdir /linux_lun”
7. Make its entry in fstab file as below-
“/dev/cinder-volumes/lsan1 /linux_lun gfs2 defaults 0 0”
8. Check the gfs2 status to verify currently activated mounts and activate the newly created.
“service gfs2 status” | “service gfs2 reload”
9. Go to another host- “ssh 10.100.10.3”
10. Verify the volume group status -- “vgs”
11. Finally activate the LVM-- “vgchange -ay cinder-vloumes”
Links:
Cosistent device name to LUN-
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/DM_Multipath/mul
tipath_consistent_names.html
adding to existing vg-
https://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/VG_remove_PV.html
formatting with gfs2
1) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Global_File_
System_2/ch-manage.html#s1-manage-makefs
2) http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html/Clusters_from_Scratch/ch08s03s0
2.html
3) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Globa
l_File_System_2/index.html
4) https://access.redhat.com/solutions/17401
ACTIVATING LVM
http://www.unixarena.com/2013/10/how-to-install-cluster-lvm2-and-gfs2-on.html
SMB MOUNTING-
COMMAND- /usr/bin/smbclient \\\\10.100.11.59\\pub -U kamal