Scribd
Upload
40 views

VCS Building Blocks

A cluster is a collection of independent systems that work together under a management framework for increased availability. VERITAS Cluster Server (VCS) detects faults and performs automated failover of application services. Key components include service groups containing resources like IP addresses and mounts that are managed by agents. Low Latency Transport and Group Membership Services/Atomic Broadcast provide cluster communication and membership monitoring. The configuration is maintained in memory by the High Availability Daemon and stored on disk. VCS supports various failover configurations including active/passive, N-to-1, N+1, active/active, and N-to-N.

Uploaded by

mahabooba
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
40 views

VCS Building Blocks

A cluster is a collection of independent systems that work together under a management framework for increased availability. VERITAS Cluster Server (VCS) detects faults and performs automated failover of application services. Key components include service groups containing resources like IP addresses and mounts that are managed by agents. Low Latency Transport and Group Membership Services/Atomic Broadcast provide cluster communication and membership monitoring. The configuration is maintained in memory by the High Availability Daemon and stored on disk. VCS supports various failover configurations including active/passive, N-to-1, N+1, active/active, and N-to-N.

Uploaded by

mahabooba
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 31

VCS Building Blocks

Topic 1: Cluster Terminology


After completing this topic, you
will be able to define clustering
terminology.

A Nonclustered Computing Environment

Definition of a Cluster
A cluster is a collection of multiple
independent systems working
together under a management
framework for increased service
availability.

Application
Node
Storage
Cluster Interconnect

Definition of VERITAS Cluster Server and


Failover
VCS detects faults and
performs automated failover.

Application
Node
Failed Node
Storage
Cluster
Interconnect

Definition of an Application Service


An application service is a collection
of all the hardware and software
components required to provide a
service.
If the service must be migrated to
another system, all components
need to be moved in an orderly
fashion.
Examples include Web servers,
databases, and applications.

Definition of a Service Group

A service group is a virtual container


that enables VCS to manage an
application service as a unit.
All components required to
provide the service, and the
relationships between these
components, are defined within
the service group.
A service group has attributes that
define its behavior, such as where
it can start and run.

Service Group Types


Failover:
The service group can be online on only one cluster
system at a time.
VCS migrates the service group at the administrators
request and in response to faults.

Parallel
The service group can be online on multiple cluster
systems simultaneously.
An example is Oracle Real Application Cluster (RAC).

Hybrid
This is a special-purpose type of service group used to manage
service groups in replicated data clusters (RDCs). RDCs use
replication between systems at different sites instead of shared
storage.

Definition of a Resource
Resources are VCS objects that correspond to the
hardware or software components of an application
service.
Each resource must have a unique name throughout the
cluster. Choosing names that reflect the service group
name makes it easy to identify all resources in that
group, for example, WebIP in the WebSG group.
Resources are always contained within service groups.
Resource categories include:
Persistent
None (NIC)
On-only (NFS)
Nonpersistent
On-off (Mount)

Resource Dependencies
Resources in a service group have a defined
dependency relationship, which determines the
online and offline order of the resource.
A parent resource depends
on a child resource.
There is no limit to the
number of parent and child
resources.
Persistent resources, such
as NIC, cannot be parent
resources.
Dependencies cannot be
cyclical.

Parent

Parent/child

Child

Resource Attributes
Resource attributes define
an individual resource.
The attribute values are
used by VCS to manage
the resource.
Resources can have
required and optional
attributes, as specified
by the resource type
definition.

WebMount
resource

Solaris

mount F vxfs /dev/vx/dsk/WebDG/WebVol /Web

Resource Types
Resources are classified
by type.
The resource type
specifies the
attributes needed to
define a resource of
that type.
For example, a Mount
resource has different
properties than an IP
resource.
Solaris
mount [-F FSType] [options] block_device mount_point

Agents: How VCS Controls Resources


Each resource type has a corresponding agent
process that manages all resources of that type.
Agents have one or more entry points that perform a set of
actions on resources.
Each system runs one agent for each active resource type.
/web /log

10.1.2.3

online

WebDG WebVol logVol

eri0

offline
monitor
IP

NIC

Mount
Disk
Group

Volume

clean

Topic 2: Cluster Communication


After completing this topic, you
will be able to describe cluster
communication mechanisms.

Cluster Communication
A cluster interconnect provides a communication
channel between cluster nodes.
The cluster interconnect
serves to:
Determine which systems are
members of the cluster using a
heartbeat mechanism.
Maintain a single view of the
status of the cluster
configuration on all systems in
the cluster membership.

Low-Latency Transport (LLT)


LLT:

LLT

LLT

Is responsible for sending


heartbeat messages
Transports cluster
communication traffic to
every active system
Balances traffic load
across multiple network
links
Maintains the
communication link state
Is a nonroutable protocol
Runs on an Ethernet
network

Group Membership Services/Atomic


Broadcast (GAB)
GAB:
Performs two functions:

GAB

GAB
LLT

LLT

Manages cluster
membership; referred to
as GAB membership
Sends and receives
atomic broadcasts of
configuration information

Is a proprietary
broadcast protocol
Uses LLT as its
transport mechanism

The Fencing Driver

Reboot
Fence

Fence

GAB
LLT

GAB
LLT

Fencing:
Monitors GAB to detect
cluster membership
changes
Ensures a single view
of cluster membership
Prevents multiple nodes
from accessing the
same Volume Manager
4.x shared storage
devices

The High Availability Daemon (HAD)


The VCS engine, the
high availability
daemon:
HAD
hashadow

Fence
GAB
LLT

Runs on each system


in the cluster
Maintains configuration
and state information
for all cluster resources
Manages all agents

The hashadow daemon


monitors HAD.

Comparing VCS Communication Protocols


and TCP/IP

HAD

User Processes

iPlanet

hashadow

TCP

GAB
Kernel Processes

IP

LLT
NIC

Hardware

NIC

Topic 3: Maintaining the Cluster


Configuration
After completing this topic, you
will be able to describe how the
cluster maintains the
configuration.

Maintaining the Cluster Configuration

HAD
main.cf

hashadow

HAD
hashadow

HAD maintains a
replica of the cluster
configuration in
memory on each
system.
Changes to the
configuration are
broadcast to HAD on
all systems
simultaneously by
way of GAB using
LLT.
The configuration is
preserved on disk in
the main.cf file.

VCS Configuration Files

main.cf

include "types.cf"
cluster vcs (
UserNames = { admin = ElmElgLimHmmKumGlj }
Administrators = { admin }
CounterInterval = 5
A simple text file is used to
)
store the cluster configuration
system S1 (
on disk.
)
The file contents are described
system S2 (
in detail later in the course.
)
group WebSG (
SystemList = { S1 = 0, S2 = 1 }
)
Mount WebMount (
MountPoint = "/web"
BlockDevice = "/dev/vx/dsk/WebDG/WebVol"
FSType = vxfs
FsckOpt = "-y"
)

Topic 4: VCS Architecture


After completing this topic, you
will be able to describe the VCS
architecture.

VCS Architecture
Agents monitor resources on
each system and provide
status to HAD on the local
system.
HAD on each system sends
status information to GAB.
GAB broadcasts
configuration information to
all cluster members.
LLT transports all cluster
communications to all cluster
nodes.
HAD on each node takes
corrective action, such as
failover, when necessary.

Topic 5: Supported Failover


Configurations
After completing this topic, you
will be able to describe the
failover configurations supported
by VCS.

Active/Passive

Before Failover

After Failover

Active/Passive N-to-1

Before Failover

After Failover

Active/Passive N + 1
Standby Server

After Failover

Before Failover

Standby Server

After Repair

Active/Active

Before Failover

After Failover

N-to-N

Before Failover

After Failover

You might also like