Editing Gspc Architecture with LUN Management

''Auto-generated from the uploaded PDF [[:File:Gspc_Architecture_with_LUN_Management.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.''

<pre>
<nowiki>
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
</nowiki>
</pre>