Vcs and Oracle Ha
Vcs and Oracle Ha
I shall not be liable for any damages that you may incur as a result of attempting anything in this
training program.
I am responsible for any errors in this document and I apologize in advance for this. I am still in the
learning mode and will try and make corrections as things come up.
When in DOUBT please google and search for articles on Symantec's site, for instance I did not know
that one does not have to assign IP addresses to the private interconnects, I stood corrected after
reading:
http://www.symantec.com/connect/forums/configure-llt-and-gab-veritas-cluster
Please take all careful precautions while handling electrical equipment. Some equipment may be
physically heavy and/or cause you distress in some ways.
The training notes that follow are a kind of guide for you to refer back to. I intend on making this an
interactive session, so please try to follow the
video, you can always go back to the notes and rewind the video as well.
Veritas is a trademark of Symantec corp and/or of Veritas. RHEL is a trademark of Red Hat. Oracle is a
trademark of Oracle. There are other various trademarks no attempt is made to infringe. Apology as
necessary is made in advance.
This guide may prepare you to work with the daily routine tasks of veritas cluster server on RHEL.
This guide may be useful for the following tasks:
1)Understand the meaning of clustering and High Availibility.
2)Understand the components of Veritas Cluster server.
3)Installing Veritas Cluster Server
4)Installing Oracle Database as a highly available service (this means it will run on one node if another
node fails).
5)Basic maintenance of a Veritas Cluster.
6)Troubleshooting
7)Interview questions.
This guide is best followed by actually doing all the steps presented herein.
I am using a HP DL580 G5 with 4 quad core processors and 32GB of RAM. It takes SFF(small form
factor) SAS drives.
I have in the past successfully used an i7 PC with windows operating system(you may use RHEL),
8GB of Ram(this is the very least recommended) and about 350GB of disk space. A network interface
is required. An internet connection is required. Free accounts at Symantec(for downloading the trial
version of Veritas Cluster Server – SFHA – Storage Foundation High Availibility) and at Oracle(trial
edition of Oracle Database Enterprise version) are essential.
In Virtualbox(free virtualization technology that works on both windows and on Linux) I am giving
2048MB to both VM's and 1024MB to the virtualised storage(oprnfiler). I am designating one cpu each
for all three. So, for the i7 case, on an 8GB physical host this leaves 8-2-2-1=3GB for the underlying
operating system. And, leaves, 4-1(openfiler)-1(node1)-1(node2)=1 core(cpu) for the base physical
system hosting everything of the 4core cpu i7 processor.
Where to buy this hardware: I suggest googling: HP DL 580 G5 and i7 16GB and checking out Ebay.
Down to it.
What is a cluster:
A computer cluster consists of a set of loosely or tightly connected computers(here called nodes) that
work together so that, in many respects, they can be viewed as a single system. Computer clusters have
each node set to perform the same task, controlled and scheduled by software(in our case by VCS).
The components of a cluster are usually connected to each other through fast local area networks
("LAN"), with each node (computer used as a server) running its own instance of an operating system.
All of the nodes use IDENTICAL hardware and IDENTICAL operating system.
They are usually deployed to improve performance and availability over that of a single computer,
while typically being much more cost-effective than single computers of comparable speed or
availability.
This image below shows how more resilience is built into a cluster, this type of cluster is what you are
likely to encounter at work. Please NOTE the presence on dual NIC's for the public interface, they are
multipathed or bonded together, so that if one NIC on the public network goes down the other takes
over.
Also please note the presence of three storage interfaces per node , one is going to the local disk, two
on each node are going to the shared storage, again this is multipathing of the storage adapters,
commonly called HBA's(host based adapter), again this can be accomplished in a variety of ways, you
might have heard of powerpath/vxdmp/linux native multipathing etc.
A cluster typically has two or more nodes(computers) connected to each other by TWO networks. A
high speed private network which usually consists of two links (two network cards dedicated for the
private interconnect) and a second network which is the public network via which clients(you and me
and application users) can access the cluster(for them it is a single computer.
The other facet to a cluster is the requirement of shared storage. Shared storage are disk(s) which are
connected to all the nodes of the cluster.
The premise is not that complicated. The premise of clustering being that if one node of the cluster
goes down/crashes the other node picks up. To this end both nodes of the cluster need to be aware if
another one crashes, this is accomplished usually by the presence of the private network of high speed
interconnect. When one node crashes the application hosted on the cluster “fails over” to the other node
of the cluster. This is HIGH AVAILIBILITY.
You might have noticed how ebay/google/amazon etc do not crash, this is again because behind the
ebay.com/google/com/amazon.com is a cluster of two or more computers which provides redundancy
to the entire setup.
A cluster hence consists of hardware and the cluster software(which actually provides the clustering
between the nodes of the cluster).
There are several commercially available clustering softwares, the important ones are:
a)Veritas Cluster Server
b)Sun Clustering
c)RHEL/CentOS native clustering
VCS Basics
VCS Basics
A single VCS cluster consists of multiple systems connected in various combinations to shared
storage devices. VCS monitors and controls applications running in the cluster, and restarts
applications in response to a variety of hardware or software faults. Client applications continue
operation with little or no downtime. Client workstations receive service over the public network
from applications running on the VCS systems. VCS monitors the systems and their services. VCS
systems in the cluster communicate over a private network.
Switchover and Failover
A switchover is an orderly shutdown of an application and its supporting resources on one server and
a controlled startup on another server.
A failover is similar to a switchover, except the ordered shutdown of applications on the original
node may not be possible, so the services are started on another node. The process of starting the
application on the node is identical in a failover or switchover.
CLUSTER COMPONENTS:
Resources
Resources are hardware or software entities, such as disk groups and file systems, network interface
cards (NIC), IP addresses, and applications. Controlling a resource means bringing it online
(starting), taking it offline (stopping), and monitoring the resource.
Resource Dependencies:
Resource dependencies determine the order in which resources are brought online or taken offline
when their associated service group is brought online or taken offline. In VCS terminology, resources
are categorized as parents or children. Child resources must be online before parent resources can
be brought online, and parent resources must be taken offline before child resources can be taken
offline.
Resource Categories:
On-Off: VCS starts and stops On-Off resources as required. For example, VCS imports a disk group
when required, and deports it when it is no longer needed.
On-Only: VCS starts On-Only resources, but does not stop them. For example, VCS requires NFS
daemons to be running to export a file system. VCS starts the daemons if required, but does not
stop them if the associated service group is taken offline.
Persistent: These resources cannot be brought online or taken offline. For example, a network
interface card cannot be started or stopped, but it is required to configure an IP address. VCS
monitors Persistent resources to ensure their status and operation. Failure of a Persistent resource
triggers a service group failover.
Service Groups
A service group is a logical grouping of resources and resource dependencies. It is a management
unit that controls resource sets. A single node may host any number of service groups, each
providing a discrete service to networked clients. Each service group is monitored and managed
independently. Independent management enables a group to be failed over automatically or
manually idled for administration or maintenance without necessarily affecting other service
groups. VCS monitors each resource in a service group and, when a failure is detected, restarts that
service group. This could mean restarting it locally or moving it to another node and then restarting
it.
Types of Service Groups:
Fail-over Service Groups
A failover service group runs on one system in the cluster at a time.
Parallel Service Groups
A parallel service group runs simultaneously on more than one system in the cluster.
Hybrid Service Groups
A hybrid service group is for replicated data clusters and is a combination of the two groups cited
above. It behaves as a failover group within a system zone and a parallel group across system zones.
It cannot fail over across system zones, and a switch operation on a hybrid group is allowed only if
both systems are within the same system zone.
The ClusterService Group
The Cluster Service group is a special purpose service group, which contains resources required by
VCS components. The group contains resources for Cluster Manager (Web Console), Notification, and
the wide-area connector (WAC) process used in global clusters.
The ClusterService group can fail over to any node despite restrictions such as “frozen.” It is the
first service group to come online and cannot be auto disabled. The group comes online on the first
node that goes in the running state.
Agents
Agents are VCS processes that manage resources of predefined resource types according to
commands received from the VCS engine, HAD. A system has one agent per resource type that
monitors all resources of that type; for example, a single IP agent manages all IP resources.
When the agent is started, it obtains the necessary configuration information from VCS. It then
periodically monitors the resources, and updates VCS with the resource status. VCS agents are
multithreaded, meaning a single VCS agent monitors multiple resources of the same resource type
on one host. VCS monitors resources when they are online and offline to ensure they are not started
on systems on which they are not supposed to run. For this reason, VCS starts the agent for any
resource configured to run on a system when the cluster is started. If no resources of a particular
type are configured, the agent is not started.
Agent Operation:
Online—Brings a specific resource ONLINE from an OFFLINE state.
Offline—Takes a resource from an ONLINE state to an OFFLINE state.
Monitor—Tests the status of a resource to determine if the resource is online or offline.
Clean—Cleans up after a resource fails to come online, fails to go offline, or fails while in an ONLINE
state.
Action—Performs actions that can be completed in a short time (typically, a few seconds), and
which are outside the scope of traditional activities such as online and offline.
Info—Retrieves specific information for an online resource.
Multiple Systems
VCS runs in a replicated state on each system in the cluster. A private network enables the systems
to share identical state information about all resources and to recognize which systems are active,
which are joining or leaving the cluster, and which have failed. The private network requires two
communication channels to guard against network partitions.
For the VCS private network, two types of channels are available for heartbeating: network
connections and heartbeat regions on shared disks. The shared disk region heartbeat channel is used
for heartbeating only, not for transmitting information as are network channels. Each cluster
configuration requires at least two channels between systems, one of which must be a network
connection. The remaining channels may be a combination of network connections and heartbeat
regions on shared disks. This requirement for two channels protects your cluster against network
partitioning. Also it’s recommended to have at least one heart beat disk region on each I/O shared
between systems. E.g. two-system VCS cluster in which sysA and sysB have two private network
connections and another connection via the heartbeat disk region on one of the shared disks. If one
of the network connections fails, two channels remain. If both network connections fail, the
condition is in jeopardy, but connectivity remains via the heartbeat disk.
Shared Storage
A VCS hardware configuration typically consists of multiple systems connected to share storage via
I/O channels. Shared storage provides multiple systems an access path to the same data, and
enables VCS to restart applications on alternate systems when a system fails.
Cluster Control, Communications, and Membership
Cluster communications ensure VCS is continuously aware of the status of each system’s service
groups and resources.
High-Availability Daemon (HAD)
The high-availability daemon, or HAD, is the main VCS daemon running on each system. It is
responsible for building the running cluster configuration from the configuration files, distributing
the information when new nodes join the cluster, responding to operator input, and taking
corrective action when something fails. It is typically known as the VCS engine. The engine uses
agents to monitor and manage resources. Information about resource states is collected from the
agents on the local system and forwarded to all cluster members. HAD operates as a replicated
state machine (RSM). This means HAD running on each node has a completely synchronized view of
the resource status on each node. The RSM is maintained through the use of a purpose-built
communications package consisting of the protocols Low Latency Transport (LLT) and Group
Membership Services/Atomic Broadcast (GAB).
Low Latency Transport (LLT)
VCS uses private network communications between cluster nodes for cluster maintenance. The Low
Latency Transport functions as a high-performance, low-latency replacement for the IP stack, and is
used for all cluster communications.
Traffic Distribution
LLT distributes (load balances) internode communication across all available private network links.
This distribution means that all cluster communications are evenly distributed across all private
network links (maximum eight) for performance and fault resilience. If a link fails, traffic is
redirected to the remaining links.
Heartbeat
LLT is responsible for sending and receiving heartbeat traffic over network links. This heartbeat is
used by the Group Membership Services function of GAB to determine cluster membership.
The system administrator configures LLT by creating the configuration files /etc/llthosts, which lists
all the systems in the cluster, and /etc/llttab, which describes the local system’s private network
links to the other systems in the cluster.
Group Membership Services/Atomic Broadcast (GAB)
The Group Membership Services/Atomic Broadcast protocol (GAB) is responsible for cluster
membership and cluster communications.
Cluster Membership
GAB maintains cluster membership by receiving input on the status of the heartbeat from each node
via LLT. When a system no longer receives heartbeats from a peer, it marks the peer as DOWN and
excludes the peer from the cluster.
Cluster Communications
GAB’s second function is reliable cluster communications. GAB provides guaranteed delivery of
point-to-point and broadcast messages to all nodes.
The system administrator configures GAB driver by creating a configuration file (/etc/gabtab).
Now we will describe how we will use freely available and not so freely available software for learning
Veritas Cluster. We will essentially virtualise everything.
At the workplace, you will have two or more physical servers as nodes of the cluster. Each physical
machine will be a node. For our training we will use two virtual machines running on Oracle's
Virtualbox as the “two physical machines”.
At the workplace you will most likely have two NICS, bonded together, dedicated to one private
interconnect. I apologize that this is not clear in any of the diagrams. So you will have 4 NIC's
dedicated to 2 private interconnects per node. Again this is called NIC bonding. In our training we will
not use bonding, rather we will assign two bridged interfaces for the two NIC's that serve the purpose
of private interconnect.
At the workplace you will have two HBA's(SAN adapters) bonded together(to appear one), per node of
the cluster connected to the SAN. This connection will be emulated here over the public NIC via the
use of iSCSI technology. Hence we will for our training, virtualize the SAN(storage area network). We
will us e openfiler for this purpose.
For our two nodes we will use two RHEL 6.6 Virtual Machines. A virtual machine is a computer that is
virtual. To host virtual computers we need a virtualization software and the hardware that supports it.
Again you may install Linux on your hardware and install Oracle VirtualBox on top of Linux or if you
are using a PC with windows operating system, install virtualbox on it.
The first step is to enable hardware virtualization technology on your computer. Please try following
these links, they may help:
http://www.sysprobs.com/disable-enable-virtualization-technology-bios
http://www.tomshardware.com/answers/id-1715638/enable-hardware-virtualization-bios.html
If you have difficulty with this step. Please consider joining a forum and asking for help. You will not
be able to proceed in configuring anything till you go past this step.
The next step is to install the virtualization software over which our virtual computers henceforth
known as virtual machines(VM's) will run on, there are many options, we will use the freely available
Oracle Virtualbox, you may download it from:
https://www.virtualbox.org/
Please also obtain the openfiler iso image. Why do we need openfiler: We will virtualize shared storage
using it. Instead of buying expensive hardware to use for the shared storage we will instead go with the
freely available virtualized storage application called openfiler. You may download openfiler from:
https://www.openfiler.com/community/download
Please go ahead and install Oracle Virtual Box. After this is done, please follow the following steps:
Select New and choose the path of the RHEL 6.x iso image and add a total of three bridged network
interfaces as shown in the below steps.
Give it a name, say, node1
Giving it 2048MB of RAM
click “Create”
Click “Next”
Click “Next”
Make it a 64GB disk
Click settings
Click Network
Choose “Bridged Adapter”
Select “Adapter2”
Same for “Adapter 3”
Click “Storage Next”
Click “OK”
Now we are ready to start this VM. Please click on “Start”.
Tab to “Skip” and hit enter
Next Next Next
“Yes, discard any data”
Select the default New York time zone
Select a password.
Use All Space
Reboot
Login
DEVICE=eth0
#HWADDR=08:00:27:B6:47:F7
TYPE=Ethernet
UUID=afb738f2-64e1-4203-8ad6-79a3dd5679d4
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=192.168.0.189
DNS1=192.168.0.1
GATEWAY=192.168.0.1
NOTE: Please replace DNS1 and GATEWAY by your routers IP. Please note NM_CONTROLLED=no
Also do this:
[root@node1 ~]# service NetworkManager stop
Stopping NetworkManager daemon:
[root@node1 ~]# chkconfig NetworkManager off
[root@node1 ~]#
Then:
[root@node1 ~]# service network restart
Shutting down interface eth0: Device state: 3 (disconnected)
[ OK ]
Shutting down interface eth1: [ OK ]
Shutting down interface eth2: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: Active connection state: activated
Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/2
[ OK ]
[root@node1 ~]#
Now we will disable two features, one is selinux and the other is iptables:
[root@node1 ~]#
Then, do:
Now we will power it down and clone it into another system called node2.
vi /etc/sysconfig/network
reboot
Now we have both VM's which will be the two nodes of our cluster up and running.
Now we will install over virtual storage area network. This is openfiler. To do this we will again go to
virtualbox.
username is “openfiler”
password is “password”
Enable the services:
Now power it down and add a drive to it. This drive will be the shared storage for our cluster. We will
give it 40GB. Please observe below:
Highlight the openfiler VM:
Click “Add Hard Disk”
Create New Disk
Please select “Fixed Disk” see below:
Click “Create”
Please click “Ok”
As you may observe an additional drive has been allocated. Now we will configure this as an iSCSI
target in openfiler.
Click on volumes tab and then on the right side on “block devices”
NOTE: PLEASE DO NOT TOUCH THE DISK WITH THREE PARTITIONS, THAT IS THE
OPENFILER BOOT DRIVE Now, we click on /dev/sdb
NOTE: PLEASE DO NOT TOUCH THE DISK WITH THREE PARTITIONS, THAT IS THE
OPENFILER BOOT DRIVE Now, we click on /dev/sdb
Click Create
Click Create
NOW GO TO RIGHT PLANE AND SELECT ISCSI TARGETS
Click on “Map”
If the steps outlined here are not clear, then, please refer to this web page:
http://dl.faraznetwork.ir/Files/Openfiler%20Configuration.pdf
You may ignore the section on “Configuring Network Settings”.
Now start node1 and node 2 and on both nodes launch putty sessions to them. On EACH node do this:
NOTE: You may use any of the identifiers, your's will be different than mine.
[root@node2 ~]#
[root@node1 ~]#
So people this is the beauty of shared storage, accessible from both nodes (/dev/sdb is accessible from
node1 and from node2).
Now, we will format this lun /dev/sdb
So, now we are free to install VCS cluster software on these two nodes and then install Oracle on the
shared storage (so that when one node crashes the other node picks up the oracle database).
Kinda late in the day, but your file /etc/sysconfig/network should look like this:
Now we will edit the hosts file on both nodes and make entries for the nodes in there. This is what
the /etc/hosts file will look on node1
One more thing, we need to setup the private interconnects for LLT. To do so, we will edit the files:
/etc/sysconfig/network-scripts/ifcfg-eth1
/etc/sysconfig/network-scripts/ifcfg-eth1
TRY AGAIN
On node1
[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
#HWADDR=08:00:27:61:F4:AE
TYPE=Ethernet
UUID=905581ef-c586-485c-be3c-65bb81e0b52a
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=10.10.10.10
[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
#HWADDR=08:00:27:61:F4:AE
TYPE=Ethernet
UUID=905581ef-c586-485c-be3c-65bb81e0b52a
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=10.10.10.11
[root@node1 ~]#
Now we have downloaded the SFHA(Veritas Storage Foundation High Availibility) package on node1,
we will now commence installing VCS. The download link for this is:
https://www4.symantec.com/Vrt/offer?a_id=24928
<snip>
./dvd1-redhatlinux/rhel6_x86_64/docs/dynamic_multipathing/
./dvd1-redhatlinux/rhel6_x86_64/docs/dynamic_multipathing/dmp_admin_61_lin.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/dynamic_multipathing/dmp_install_61_lin.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/dynamic_multipathing/dmp_notes_61_lin.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/getting_started.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/readme_first.txt
./dvd1-redhatlinux/rhel6_x86_64/docs/sfha_solutions/
./dvd1-redhatlinux/rhel6_x86_64/docs/sfha_solutions/sfhas_db2_admin_61_unix.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/sfha_solutions/sfhas_oracle_admin_61_unix.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/sfha_solutions/sfhas_replication_admin_61_lin.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/sfha_solutions/sfhas_smartio_solutions_61_lin.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/sfha_solutions/sfhas_solutions_61_lin.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/sfha_solutions/sfhas_tshoot_61_lin.pdf
./dvd1-redhatlinux/rhel6_x86_64/docs/sf_cluster_file_system_ha/
<snip>
Copyright (c) 2013 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo are
trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other
countries. Other names may be trademarks
of their respective owners.
The Licensed Software and Documentation are deemed to be "commercial computer software" and
"commercial computer software documentation" as defined in FAR Sections 12.212 and DFARS
Section 227.7202.
Task Menu:
Enter the 64 bit RHEL6 system names separated by spaces: [q,?] node1 node2
Either ssh or rsh needs to be set up between the local system and node2 for communication
Would you like the installer to setup ssh or rsh communication automatically between the systems?
Superuser passwords for the systems will be asked. [y,n,q,?] (y) y
Checking system
communication ............................................................................................................................................
...................................................... Done
Checking release
compatibility ...............................................................................................................................................
.................................................. Done
Checking installed
product ........................................................................................................................................................
............................................. Done
Checking prerequisite patches and
rpms .............................................................................................................................................................
............................ Done
Checking platform
version .........................................................................................................................................................
........................................... Failed
Checking file system free
space ............................................................................................................................................................
.................................... Done
Checking product
licensing ......................................................................................................................................................
............................................... Done
Performing product
prechecks .....................................................................................................................................................
.............................................. Done
CPI ERROR V-9-0-0 System node2 is running Kernel Release 2.6.32-504.el6.x86_64. Symantec
Storage Foundation and High Availability Solutions 6.1 is not supported on Kernel Release 2.6.32-
504.el6.x86_64 without additional patches. Visit
Symantec SORT web site to download the following required patches and follow the patch instructions
to install the patches:
Do you want to cleanup the communication for the systems node2? [y,n,q] (n)
Copyright (c) 2014 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo are
trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other
countries. Other names may be trademarks
of their respective owners.
The Licensed Software and Documentation are deemed to be "commercial computer software" and
"commercial computer software documentation" as defined in FAR Sections 12.212 and DFARS
Section 227.7202.
Task Menu:
This Symantec product may contain open source and other third party materials that are subject to a
separate license. See the applicable Third-Party Notice at
http://www.symantec.com/about/profile/policies/eulas
Do you agree with the terms of the End User License Agreement as specified in the
storage_foundation_high_availability/EULA/en/EULA_SFHA_Ux_6.2.pdf file present on media?
[y,n,q,?] y
Checking system
communication ............................................................................................................................................
...................................................... Done
Checking release
compatibility ...............................................................................................................................................
.................................................. Done
Checking installed
product ........................................................................................................................................................
............................................. Done
Checking prerequisite patches and
rpms .............................................................................................................................................................
............................ Done
Checking platform
version .........................................................................................................................................................
............................................. Done
Checking file system free
space ............................................................................................................................................................
.................................... Done
Checking product
licensing ......................................................................................................................................................
............................................... Done
Performing product
prechecks .....................................................................................................................................................
.............................................. Done
The following Symantec Storage Foundation and High Availability rpms will be installed on all
systems:
To comply with the terms of Symantec's End User License Agreement, you have 60 days to either:
* Enter a valid license key matching the functionality in use on the systems
* Enable keyless licensing and manage the systems with a Management Server. For more details visit
http://go.symantec.com/sfhakeyless. The product is fully functional during these 60 days.
1) SF Standard HA
2) SF Enterprise HA
b) Back to previous menu
I/O Fencing
It needs to be determined at this time if you plan to configure I/O Fencing in enabled or disabled mode,
as well as help in determining the number of network interconnects (NICS) required on your systems.
If you configure I/O Fencing in
enabled mode, only a single NIC is required, though at least two are recommended.
A split brain can occur if servers within the cluster become unable to communicate for any number of
reasons. If I/O Fencing is not enabled, you run the risk of data corruption should a split brain occur.
Therefore, to avoid data
corruption due to split brain in CFS environments, I/O Fencing has to be enabled.
When [b] is presented after a question, 'b' may be entered to go back to the first question of the
configuration set.
When [?] is presented after a question, '?' may be entered for help or additional information about the
question.
Following each set of questions, the information you have entered will be presented for confirmation.
To repeat the set of questions and correct any previous errors, enter 'n' at the confirmation prompt.
No configuration changes are made to the systems until all configuration questions are completed and
confirmed.
On Linux systems, only activated NICs can be detected and configured automatically.
The cluster cannot be configured if the cluster ID 77 is in use by another cluster. Installer can perform a
check to determine if the cluster ID is duplicate. The check will take less than a minute to complete.
Would you like to check if the cluster ID is in use by another cluster? [y,n,q] (y) n
Enter the NIC for Virtual IP of the Cluster to use on node1: [b,q,?] (eth0)
Is eth0 to be the public NIC used by all systems? [y,n,q,b,?] (y)
Enter the Virtual IP address for the Cluster: [b,q,?] 192.168.0.200
Enter the NetMask for IP 192.168.0.200: [b,q,?] (255.255.255.0)
NIC: eth0
IP: 192.168.0.200
NetMask: 255.255.255.0
Running VCS in Secure Mode guarantees that all inter-system communication is encrypted, and users
are verified with security credentials.
When running VCS in Secure Mode, NIS and system usernames and passwords are used to verify
identity. VCS usernames and passwords are no longer utilized when a cluster is running in Secure
Mode.
Would you like to configure the VCS cluster in secure mode? [y,n,q,?] (y) n
Fencing configuration
1) Configure Coordination Point client based fencing
2) Configure disk based fencing
3) Configure majority based fencing
When [b] is presented after a question, 'b' may be entered to go back to the first question of the
configuration set.
When [?] is presented after a question, '?' may be entered for help or additional information about the
question.
Following each set of questions, the information you have entered will be presented for confirmation.
To repeat the set of questions and correct any previous errors, enter 'n' at the confirmation prompt.
No configuration changes are made to the systems until all configuration questions are completed and
confirmed.
On Linux systems, only activated NICs can be detected and configured automatically.
The cluster cannot be configured if the cluster ID 77 is in use by another cluster. Installer can perform a
check to determine if the cluster ID is duplicate. The check will take less than a minute to complete.
Would you like to check if the cluster ID is in use by another cluster? [y,n,q] (y) n
Enter the NIC for Virtual IP of the Cluster to use on node1: [b,q,?] (eth0)
Is eth0 to be the public NIC used by all systems? [y,n,q,b,?] (y)
Enter the Virtual IP address for the Cluster: [b,q,?] 192.168.0.200
Enter the NetMask for IP 192.168.0.200: [b,q,?] (255.255.255.0)
NIC: eth0
IP: 192.168.0.200
NetMask: 255.255.255.0
Running VCS in Secure Mode guarantees that all inter-system communication is encrypted, and users
are verified with security credentials.
When running VCS in Secure Mode, NIS and system usernames and passwords are used to verify
identity. VCS usernames and passwords are no longer utilized when a cluster is running in Secure
Mode.
Would you like to configure the VCS cluster in secure mode? [y,n,q,?] (y) n
CPI WARNING V-9-40-6338 Symantec recommends that you install the cluster in secure mode. This
ensures that communication between cluster components is encrypted and cluster information is visible
to specified users only.
Are you sure that you want to proceed with non-secure installation? [y,n,q] (n) y
A user name
A password for the user
User privileges (Administrator, Operator, or Guest)
Do you wish to accept the default cluster credentials of 'admin/password'? [y,n,q] (y)
Performing SFHA
configuration ...............................................................................................................................................
................................................... Done
Starting
vxdmp ..........................................................................................................................................................
....................................................... Done
Starting
vxio ..............................................................................................................................................................
.................................................... Done
Starting
vxspec ..........................................................................................................................................................
...................................................... Done
Starting
vxconfigd ....................................................................................................................................................
......................................................... Done
Starting
vxesd ...........................................................................................................................................................
...................................................... Done
Starting
vxrelocd .......................................................................................................................................................
....................................................... Done
Starting
vxcached ......................................................................................................................................................
........................................................ Done
Starting
vxconfigbackupd .........................................................................................................................................
.............................................................. Done
Starting
vxattachd .....................................................................................................................................................
........................................................ Done
Starting
xprtld ...........................................................................................................................................................
..................................................... Done
Starting
vxportal .......................................................................................................................................................
....................................................... Done
Starting
fdd ...............................................................................................................................................................
.................................................... Done
Starting
vxcafs ..........................................................................................................................................................
...................................................... Done
Starting
llt .................................................................................................................................................................
.................................................. Done
Starting
gab ...............................................................................................................................................................
.................................................... Done
Starting
amf ..............................................................................................................................................................
..................................................... Done
Starting
had ...............................................................................................................................................................
.................................................... Done
Starting
CmdServer ..................................................................................................................................................
........................................................... Done
Starting
vxodm ..........................................................................................................................................................
....................................................... Done
Performing SFHA poststart
tasks .............................................................................................................................................................
................................... Done
Fencing configuration
1) Configure Coordination Point client based fencing
2) Configure disk based fencing
3) Configure majority based fencing
Select the fencing mechanism to be configured in this Application Cluster: [1-3,q,?] q
-- SYSTEM STATE
-- System State Frozen
A node1 RUNNING 0
A node2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
So, this command, you will use al the time, hastatus -sum. Please note it.
For this training all you need to know about Veritas File System is this:
One or more physical or virtual disks go to create a veritas disk group, a veritas disk group goes into
the creation of a veritas volume and finally a veritas file system is created on a veritas volume.
So, one or more disks->veritas disk group->veritas volume->veritas file system. Hence to increase the
size of an existing file system we have to add disks to the underlying diskgroup and then increase the
volume and filesystem. This is important for WORK and the process is documented at the end of this
manual.
[root@node1 ~]# vxdiskadm
NOTE: This is Veritas Storage Foundation command. We will create a vxfs(veritas file system) on this
shared disk and install oracle on it.
Use this operation to add one or more disks to a disk group. You can
add the selected disks to an existing disk group or to a new disk group
that will be created as a part of the operation. The selected disks may
also be added to a disk group as spares. Or they may be added as
nohotuses to be excluded from hot-relocation use. The selected
disks may also be initialized without adding them to a disk group
leaving the disks available for use as replacement disks.
More than one disk may be entered at the prompt. Here are
some disk selection examples:
disk_0
A new disk group will be created named newdg and the selected disks
will be added to the disk group with default disk names.
disk_0
The following disk device has a valid partition table, but does not appear to
have been initialized for the Volume Manager. If there is data on the disk
that should NOT be destroyed you should encapsulate the existing disk
partitions as volumes instead of adding the disk as a new disk.
Output format: [Device_Name]
disk_0
disk_0
Now that we have a diskgroup we will create a volume on top of it and on top of that we will create a
VxFS (Veritas File System) and on top of that we will install Oracle.
So, first things first. Creating a volume.
We know that we have a 36GB lun from openfiler (remember our virtual SAN), so we will choose a
size that works (some disk space is used up while initializing the disk and some while adding it to the
disk group)
Now we will add this volume(and associated filesystem) into Veritas Cluster Server (VCS) control.
[root@node1 vx]#
[root@node1 vx]# hares -add diskgroup_resource DiskGroup new_servicegroup
NOTE: we are now adding resources to the service group which we created. The first resource is the
diskgroup, we are naming our resource “diskgroup_resource” and it is of the type “DiskGroup”.
VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
[root@node1 vx]#
[root@node1 vx]# hares -add volume_resource Volume new_servicegroup
NOTE: We are adding a new resource of the type “Volume” to the service group.
VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
[root@node1 vx]#
[root@node1 vx]# hares -add mount_resource Mount new_servicegroup
NOTE: We are adding a new resource of type “Mount” to the service group.
VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
[root@node1 vx]#
The Critical attribute for a resource defines whether a service group fails over when the resource faults.
If a resource is configured as non-critical (by setting the Critical attribute to 0) and no resources
depending on the failed resource are critical, the service group will not fail over. VCS takes the failed
resource offline and updates the group status to ONLINE|PARTIAL. The attribute also determines
whether a service group tries to come online on another node if, during the group's online process, a
resource fails to come online.
Once all of the resources have been added to the service group, VCS must be told in which
order to bring them online. Otherwise, it will try to bring all resources on line simultaneously.
The command 'hares -link res2 res1' will create a dependency such that "res1" MUST be
online before VCS will attempt to start "res2":
Obviously the diskgroup must be operational before the volume which in turn must be available prior
to the mount resource.
Adding dependencies of the resources into VCS, this follows the format:
hares -link Resource_Name Resource_it_depends_on
[root@node1 vx]#
-- SYSTEM STATE
-- System State Frozen
A node1 RUNNING 0
A node2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
-- RESOURCES ONLINING
-- Group Type Resource System IState
-- SYSTEM STATE
-- System State Frozen
A node1 RUNNING 0
A node2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
-- SYSTEM STATE
-- System State Frozen
A node1 RUNNING 0
A node2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
SO WE HAVE BEEN ABLE TO SWITCH THE VOLUME FROM ONE NODE TO THE OTHER,
HENCE IF ONE NODE GOES DOWN(CRASHES) THE VOLUME WILL STILL BE AVAILABLE
VIA THE OTHER NODE.
Check node2
unzip linuxamd64_12102_database_1of2.zip
unzip linuxamd64_12102_database_2of2.zip
#* soft core 0
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#@student - maxlogins 4
oracle soft nproc 2048
oracle hard nproc 20480
oracle soft stack 20480
oracle hard stack 32768
oracle soft nofile 4096
# End of file
oracle hard nofile 65536
EDIT THIS FILE (/etc/sysctl.conf) OMN BOTH NODES, IT SHOULD ULTIMATELY LOOK LIKE
THIS:
# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
fs.suid_dumpable = 1
fs.aio-max-nr = 1048576
fs.file-max = 6815744
#kernel.shmall = 2097152
#kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586
net.ipv4.ip_local_port_range = 9000 65500
[root@node1 ~]#
Create the oracle user and the required groups ON BOTH NODES WITH THE SAME UID/GID,
please refer to this page:
https://docs.oracle.com/database/121/LTDQI/toc.htm#CHDJIAAI
cd database
as user oracle:
export DISPLAY=192.168.0.187:0.0 (note: <MY PC'S IP ADDRESS:0.0>
Please do a cksum verification of the downloaded files against the checksum present on Oracle's site to
ensure that your download was not corrupted while downloading. (NOTE: my download was corrupted
three times and I supposedly have a pretty good provider)
Please note that you will have to do yum installs of the many packages that are missing, please do so on
both nodes(BOTH nodes have to be kept as identical as possible).
Since this is for our training and testing we will choose desktop class
PLEASE DO not CREATE AS CONTAINER DATABASE
On the node we are installing oracle on, please do this:
VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
#This message tells us to set the “Enabled” attribute of the resource which we have added to “1” to
#ensure that VCS starts monitoring this resource, we will do it.
[root@node1 init.d]#
[root@node1 init.d]# hares -modify listener_resource TnsAdmin
/ORACLE/home/oracle/app/oracle/product/12.1.0/dbhome_1/network/admin/
#Another important Oracle resource attribute, we are modifying this hence the “hares -modify”, we are
#setting it to the location of the admin directory.
[root@node1 init.d]#
[root@node1 init.d]# hares -add oracledb_resource Oracle new_servicegroup
#Now we add the Oracle database proper as a resource to the service group.
VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
NOTE: We have to copy certain oracle related files to node2, these are already present on node1
because we did our installation of oracle database on node1.
[root@node1 init.d]# cat /etc/oratab
#
so, do this:
-- SYSTEM STATE
-- System State Frozen
A node1 RUNNING 0
A node2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
-- SYSTEM STATE
-- System State Frozen
A node1 RUNNING 0
A node2 RUNNING 0
-- GROUP STATE
-- Group System Probed AutoDisabled State
At work you will probably be asked to monitor and troubleshoot an existing installation of VCS. The
most important thing to remember is to monitor the VCS log files. These are located in
/var/VRTSvcs/log/engine_A.log
For your practice, open two terminal sessions(two putty sessions), run this command:
root@node1 ~]# hagrp -switch new_servicegroup -to node2
In the second putty session, run this command:
root@node1 ~]#tail -f /var/VRTSvcs/log/engine_A.log
This will show you everything that is happening.
As part of routine maintenance, you might be asked by the DBA to “freeze the cluster” as they do an
Oracle upgrade or apply security patches to Oracle etc. Freezing the cluster is an erroneous description
of what they want. They really want you to freeze the Oracle service group.
Freezing a service group: We freeze a service group to prevent it from failing over to another system.
This freezing process stops all online and offline procedures on the service group.
Unfreeze a frozen service group to perform online or offline operations on the service group.
The option -persistent enables the freeze to be remembered when the cluster is rebooted.
If someone asks you, how to do it, say this: "I have done it with EMC powerpath installed"
1)Request lun from storage team. Request lun be assigned a specific VNX tag, example "db_extended".
On only the node where the volume group is online, run these commands:
/etc/llttab The file contains information that is derived during installation and
is used by the utility lltconfig.
/etc/gabtab The file contains the information needed to configure the GAB driver.
This file is used by the gabconfig utility.
/ The VCS configuration file. The file contains the information that
etc/VRTSvcs/conf/config/main.cf defines the cluster and its systems.
Gabtab Entries
/sbin/gabdiskconf - i /dev/dsk/c1t2d0s2 -s 16 -S 1123
/sbin/gabdiskconf - i /dev/dsk/c1t2d0s2 -s 144 -S 1124
/sbin/gabdiskhb -a /dev/dsk/c1t2d0s2 -s 16 -p a -s 1123
/sbin/gabdiskhb -a /dev/dsk/c1t2d0s2 -s 144 -p h -s 1124
/sbin/gabconfig -c -n2
verify that GAB is operating Note: port a indicates that GAB is communicating, port h indicate
VCS is started
Cluster daemons
High Availability Daemon had
Companion Daemon hashadow
Resource Agent daemon <resource>Agent
Web Console cluster managerment daemon CmdServer
Bring the cluster into running mode from a stale state using the configuration file
from a particular server hasys -force <server_name>
stop the cluster on the local server but leave the application/s running, do not hastop -local
failover the application/s
stop cluster on local server but evacuate (failover) the application/s to another node hastop -local -evacuate
within the cluster
stop the cluster on all nodes but leave the application/s running hastop -all -force
Cluster Status
display cluster summary hastatus -summary
continually monitor cluster hastatus
verify the cluster is operating hasys -display
Cluster Details
information about a cluster haclus -display
value for a specific cluster attribute haclus -value <attribute>
modify a cluster attribute haclus -modify <attribute name> <new>
Enable LinkMonitoring haclus -enable LinkMonitoring
Disable LinkMonitoring haclus -disable LinkMonitoring
Users
add a user hauser -add <username>
modify a user hauser -update <username>
delete a user hauser -delete <username>
display all users hauser -display
System Operations
add a system to the cluster hasys -add <sys>
delete a system from the cluster hasys -delete <sys>
Modify a system attributes hasys -modify <sys> <modify options>
list a system state hasys -state
Force a system to start hasys -force
Display the systems attributes hasys -display [-sys]
List all the systems in the cluster hasys -list
Change the load attribute of a system hasys -load <system> <value>
Display the value of a systems nodeid (/etc/llthosts) hasys -nodeid
hasys -freeze [-persistent][-evacuate]
Freeze a system (No offlining system, No groups
onlining) Note: main.cf must be in write mode
Dynamic Configuration
The VCS configuration must be in read/write mode in order to make changes. When in
read/write mode the
configuration becomes stale, a .stale file is created in $VCS_CONF/conf/config. When
the configuration is put
back into read only mode the .stale file is removed.
Change configuration to read/write mode haconf -makerw
Change configuration to read-only mode haconf -dump -makero
haclus -display |grep -i 'readonly'
Check the configuration file Note: you can point to any directory as long as it has main.cf and types
convert a main.cf file into cluster commands hacf -cftocmd /etc/VRTSvcs/conf/config -dest /tmp
hacf -cmdtocf /tmp -dest /etc/VRTSvcs/conf/config
convert a command file into a main.cf file
Service Groups
haconf -makerw
hagrp -add groupw
add a service group hagrp -modify groupw SystemList sun1 1 sun2 2
hagrp -autoenable groupw -sys sun1
haconf -dump -makero
haconf -makerw
delete a service group hagrp -delete groupw
haconf -dump -makero
haconf -makerw
hagrp -modify groupw SystemList sun1 1 sun2 2 sun3 3
haconf -dump -makero
change a service group
Note: use the "hagrp -display <group>" to list attributes
haconf -makerw
hagrp -enable <group> [-sys]
haconf -dump -makero
Enable a service group. Enabled groups can only be
brought online
Note to check run the following command "hagrp -display | grep En
haconf -makerw
hagrp -disable <group> [-sys]
haconf -dump -makero
Disable a service group. Stop from bringing online
Note to check run the following command "hagrp -display | grep En
Flush a service group and enable corrective action. hagrp -flush <group> -sys <system>
Resources
haconf -makerw
hares -add appDG DiskGroup groupw
hares -modify appDG Enabled 1
add a resource hares -modify appDG DiskGroup appdg
hares -modify appDG StartVolumes 0
haconf -dump -makero
haconf -makerw
delete a resource hares -delete <resource>
haconf -dump -makero
haconf -makerw
hares -modify appDG Enabled 1
haconf -dump -makero
change a resource
Note: list parameters "hares -display <resource>"
Resource Operations
Online a resource hares -online <resource> [-sys]
Offline a resource hares -offline <resource> [-sys]
display the state of a resource( offline, online, etc) hares -state
display the parameters of a resource hares -display <resource>
Offline a resource and propagate the command to its hares -offprop <resource> -sys <sys>
children
Cause a resource agent to immediately monitor the hares -probe <resource> -sys <sys>
resource
Clearing a resource (automatically initiates the hares -clear <resource> [-sys]
onlining)
Resource Types
Add a resource type hatype -add <type>
Remove a resource type hatype -delete <type>
List all resource types hatype -list
Display a resource type hatype -display <type>
List a partitcular resource type hatype -resources <type>
Change a particular resource types attributes hatype -value <type> <attr>
Resource Agents
add a agent pkgadd -d . <agent package>
remove a agent pkgrm <agent package>
change a agent n/a
list all ha agents haagent -list
Display agents run-time information i.e has it started, haagent -display <agent_name>
is it running ?
Display agents faults haagent -display |grep Faults
Interview Questions
Basics
What are the different service group types ?
Service groups can be one of the 3 type :
1. Failover – Service group runs on one system at a time.
2. Parallel – Service group runs on multiple systems simultaneously.
3. Hybrid – Used in replicated data clusters (disaster recovery setups). SG behaves as Failover within
the local cluster and Parallel for the remote cluster.
# haconf -dump -makero (Dumps in memory configuration to main.cf and makes it read-only)
# haconf -makerw (Makes configuration writable)
Where is the VCS engine log file located ?
The VCS cluster engine logs is located at /var/VRTSvcs/log/engine_A.log. We can either directly view
this file or use command line to view it :
# hamsg engine_A
How to check the complete status of the cluster
To check the status of the entire cluster :
# hastatus -sum
How to verify the syntax of the main.cf file
To verify the syntax of the main.cf file just mention the absolute directory path to the main.cf file :
# hastop -all
3. Edit the configuration file after taking the backup and do the changes :
# cp -p /etc/VRTSvcs/conf/config/main.cf /etc/VRTSvcs/conf/config/main.cf_17march
# vi /etc/VRTSvcs/conf/config/main.cf
4. Verify the configuration file syntax :
# hastart
6. start VCS on other nodes in the cluster.
Note : This can be done in another way by just stopping VCS and leaving services running to minimize
the downtime. (hastop -all -force
# gabconfig -a
Whats the maximum number of LLT links (including high and low priority) can a cluster have ?
A cluster can have a maximum of 8 LLT links including high and low priority LLT links.
# lltstat -nvv
What are the various LLT configuration files and their function ?
LLT uses /etc/llttab to set the configuration of the LLT interconnects.
# cat /etc/llttab
set-node node01
set-cluster 02
link nxge1 /dev/nxge1 - ether - -
link nxge2 /dev/nxge2 - ether - -
link-lowpri /dev/nxge0 – ether - -
Here, set-cluster -> unique cluster number assigned to the entire cluster [ can have a value ranging
between 0 to (64k – 1) ]. It should be unique across the organization.
set-node -> a unique number assigned to each node in the cluster. Here the name node01 has a
corresponding unique node number in the file /etc/llthosts. It can range from 0 to 31.
Another configuration file used by LLT is – /etc/llthosts. It has the cluster-wide unique node number
and nodename as follows:
# cat /etc/llthosts
0 node01
1 node02
LLT has an another optional configuration file : /etc/VRTSvcs/conf/sysname. It contains short names
for VCS to refer. It can be used by VCS to remove the dependency on OS hostnames.
# cat /etc/gabtab
/sbin/gabconfig -c -n 4
here -n 4 –> number of nodes that must be communicating in order to start VCS.
# gabconfig -c -x
How to start HAD or VCS ?
To start HAD or VCS on all nodes in the cluster, the hastart command need to be run on all nodes
individually.
# hastart
What are the various ways to stop HAD or VCS cluster ?
The command hastop gives various ways to stop the cluster.
# hastop -local
# hastop -local -evacuate
# hastop -local -force
# hastop -all -force
# hastop -all
-local -> Stops service groups and VCS engine [HAD] on the node where it is fired
-local -evacuate -> migrates Service groups on the node where it is fired and stops HAD on the same
node only
-local -force -> Stops HAD leaving services running on the node where it is fired
-all -force -> Stops HAD on all the nodes of cluster leaving the services running
-all -> Stops HAD on all nodes in cluster and takes service groups offline
Resource Operations
How to list all the resource dependencies
To list the resource dependencies :
# hares -dep
How to enable/disable a resource ?
# hares -modify [resource_name] Enabled 1 (To enable a resource)
# hares -modify [resource_name] Enabled 0 (To disable a resource)
How to list the parameters of a resource
To list all the parameters of a resource :
haconf –makerw
hagrp –add SG
hagrp –modify SG SystemList node01 0 node02 1
hagrp –modify SG AutoStartList node02
haconf –dump -makero
How to check the configuration of a service group – SG ?
To see the service group configuration :
# hagrp -display SG
How to bring service group online/offline ?
To online/offline the service group on a particular node :
Troubleshooting
How to flush a service group and when its required ?
Flushing of a service group is required when, agents for the resources in the service group seems
suspended waiting for resources to be taken online/offline. Flushing a service group clears any internal
wait states and stops VCS from attempting to bring resources online.
1. Open, freeze each Service Group, and close the VCS config.
haconf -makerw
hagrp -freeze <Service Group> -persistent
haconf -dump makero
gabconfig -a
gabdiskhb -l
gabdiskx -l
gabdiskhb -d
gabdiskx -d
gabconfig -U
gabconfig -a
6. Identify the GAB kernel module number and unload it
from each system.
lltconfig -U
cd /etc/rc2.d
mv S70llt s70llt
mv S92gab s92gab
cd /etc/rc3.d
mv S99vcs s99vcs
cd /etc/rc0.d
mv K10vcs k10vcs
Starting with VCS 1.3.0, preonline and other trigger scripts must
be in /opt/VRTSvcs/bin/triggers. Also, all preonline scripts in
previous versions (such as VCS 1.1.2) must now be combined in one
preonline script.
If you are upgrading from 1.0.1 or 1.0.2, you must also remove the package
VRTSsnmp, and any packages containing a .2 extension, such as VRTScsga.2,
VRTSvcs.2, etc.
cd /etc/rc2.d
mv s70llt S70llt
mv s92gab S92gab
cd /etc/rc3.d
mv s99vcs S99vcs
cd /etc/rc0.d
mv k10vcs K10vcs
/etc/rc2.d/S70llt start
/etc/rc2.d/S92gab
/etc/rc3.d/S99vcs start
hastatus
hastatus -sum
haconf -makerw
hagrp -unfreeze <Service Group> -persistent
haconf -dump -makero
How to increase the Filesystem size in a clustered environment with EMC powerpath installed.
1) Request lun from storage team. Request lun be assigned a specific VNX tag, example
"db_extended". [NOTE: I am assuming you are using EMC VNC for storage]
2) Run df –kh as a baseline.
On both nodes of the cluster, run these commands:
3) Scan for lun's and have the os detect them:
echo "- - -" > /sys/class/scsi_host/host0/scan
echo "- - -" > /sys/class/scsi_host/host1/scan
echo "- - -" > /sys/class/scsi_host/host2/scan
echo "- - -" > /sys/class/scsi_host/host3/scan
4) Write label to disk
Fdisk /dev/sd* , option w.
5) Have powerpath detect them:
powermt config
6) Apply and save powerpath configuration:
powermt save
7) Confirm disk is seen by powerpath. Look for requested lun tag
powermt display dev=all
8) Have Veritas pick up disk
vxdctl enable
9) Verify Veritas sees new disk and is named disk properly. Disk name should match emcpower
name. If not fix with vxedit.
vxdisk –e list
On only the node where the volume group is online, run these commands:
10) Add lun to the Veritas diskgroup:
vxdiskadm, option 1
11) Use the vxresize command to resize the volume
vxresize -x -g mydg myvol <new size>G [newdiskname]