Re: [Veritas-ha] GAB and LLT cabling

[Hudes, Dana]

Patch panels are an electrical consideration only. They affect maximum 
Etherneet distance and that’s about it. The point is to have structured cabling 
so that you can move host/router/switch ports around. Also can help by using 
bundled cable though I haven’t seen that in a long time, since the 10 megabit 
days of the 1990s. Amphenol made a special connector…,

Some data centers have a workgroup switch in every cabinet for this reason. 
This was popular when gigabit Ethernet first came out, you’d have 2 gigabit 
uplinks to your gigabit core and 22 100 megabit ports for the  hosts in the 
rack. This really doesn’t buy you much distance.

The advantage of a patch panel in conjunction with row-end switches is 
combining easy moving of host ports from switch to switch along with getting 
the benefit of Ethernet distance increase. This is not really a consideration 
for heartbeat for which 10 megabit is quite adequate, but when you  have copper 
gigabit in a big facility you may run into distance limits rather quickly.

From: veritas-ha-boun...@mailman.eng.auburn.edu 
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Christian 
Gerbrandt
Sent: Wednesday, July 13, 2011 1:52 PM
To: a...@colb.com; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] GAB and LLT cabling

Maybe I’m missing something here, but is there a switch connected somewhere in 
the patch panel setup?
Just patch panel connection doesn’t work. They need to be connected to a 
network switch at some point, or crossover connected to each server.

From: veritas-ha-boun...@mailman.eng.auburn.edu 
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of a...@colb.com
Sent: 13 July 2011 17:45
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] GAB and LLT cabling

Dear List Members,

We are redoing our datacenter wiring to add lots more structure. Within this 
datacenter we have several Windows and Solaris VCS 5.x multinode clusters. 
Currently, the heartbeat (GAB/LLT) switches for these clusters are located 
within the same rack or at most 1 rack distant from the servers they are 
monitoring, and those switches are directly cabled to those servers.

We are considering consolidating all switches within the network racks, not the 
server racks. This means that the heartbeat switch cabling would attach to a 
rack patch panel, then a 40-foot cable run to the network rack patch panel, 
then to its heartbeat switch.

Does anyone have positive or negative experience with heartbeat switches 
patch-panel-separated from the servers they are monitoring?  In the best of all 
worlds it would be great to have no patch panel connections between server and 
switch, so I'm looking for real world experience with the use of intermediate 
patch panel cabling. Are there capacity or extensibility "gotchas"?  In 
particular, if we grow the clusters to 5 or 6 nodes, will the patch-panel 
approach fail?

Thanks in advance for your comments,

Andy Colb
Investment Company Institute
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] FW: I/O Fencing non-CFS

[Hudes, Dana]

I had a situation once where we used direct-attached storage (JBOD) which was 
dual-attached to the two hosts in a cluster.
Normally, all was well:  one would go down and the other would take over with 
noone trying to import the dg on both hosts at once. An operator found a way to 
make it fail: the application client wasn't responding so he blamed the server. 
He then went into the data center where we had conveniently left the keys in 
the machine and turned the keys for both to off. Then he turned them both back 
on in very quick succession (same rack, mounted one above the other at the 
time).  Both attempted to import the DG and run the application. This did not 
end well for the shared disk. It took another system admin and myself 2 days 
(and I mean day and night) to recover the volumes etc.

The operator in question not only wasn't (formally) disciplined (just told 
never, ever to put his hands on a machine without specific direction from a 
system admin to do so), he later that year got an 'attaboy' award from 
management.



From: veritas-ha-boun...@mailman.eng.auburn.edu 
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of John Cronin
Sent: Wednesday, October 13, 2010 4:08 PM
To: Everett Henson
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] FW: I/O Fencing non-CFS

As others have stated, it is indeed possible to forcibly import a disk group on 
more than one server simultaneously.

One other point - I/O fencing should protect you even in situations where 
outside servers are not using VCS or Volume Manager.

Example: A server is being decommissioned and the disks are being wiped using a 
destructive analyze program.  Unknown to anybody, one of the disks was also 
zoned to an active VCS server, which was using it (obviously a mistake, perhaps 
made many years before).  An application on the VCS server goes down and has to 
be restored from backup, because the data was corrupted; the resulting outage 
lasted several hours, and some data was lost and not recoverable.

If the VCS server had been using I/O fencing, the SCSI-3 reservation should 
have prevented the other server from accessing the disk.

This is based on a situation I was directly involved in (and asked to find the 
root cause for).

On Wed, Oct 13, 2010 at 2:44 PM, Everett Henson 
mailto:ehen...@nyx.com>> wrote:
Meant for this to go to the group...

-Original Message-
From: Everett Henson
Sent: Wednesday, October 13, 2010 2:29 PM
To: 'A Darren Dunham'
Subject: RE: [Veritas-ha] I/O Fencing non-CFS

Hmm. The consensus seems to be for Fencing in all cases where possible. I got 
my first taste of VCS on version 3.5 before Fencing was an option and I've 
never had to deal with it until a few months ago.

My thanks to everyone for your replies.

-Original Message-
From: 
veritas-ha-boun...@mailman.eng.auburn.edu
 
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu]
 On Behalf Of A Darren Dunham
Sent: Wednesday, October 13, 2010 12:27 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] I/O Fencing non-CFS

On Wed, Oct 13, 2010 at 11:39:30AM -0400, Everett Henson wrote:

> Thanks Gene. I understand it's possible to import the group manually,
> but the discussion here was around how VCS would behave normally,
> without manual intervention.

You're talking about a system designed to prevent problems in failure
situations.  If everything is happy and healthy, it wouldn't be needed.
Older versions of VCS didn't have fencing and things worked okay most
of the time.

> Wouldn't a vxdg -C to clear the private region give the server
> with the group already imported heartburn? Would it allow both
> servers simultaneous access to the storage?

Both servers will assume they have exclusive control over the data and
will begin writing information.  Yes, eventually the first server will
run into problems, but possibly not before corrupting the filesystem
and/or the disk group.  I did some tests like this (*years* ago) and
managed to end up with a disk group that I couldn't import.

> BTW, We are using two private interconnects as well as a link-lowpri already.

As long as the cluster is healthy and you don't have split-brain, then
it won't try to import on two.  The fencing is more robust in those
situations where things are unhealthy.

--
Darren
___
Veritas-ha maillist  -  
Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Please consider the environment before printing this email.

Visit our website at http://www.nyse.com



Note:  The information contained in this message and any attachment to it is 
privileged, confidential

Re: [Veritas-ha] Symantec CFS & OS Update

[Hudes, Dana]

Your vendor is presumably requiring certain OS features which are not present 
in earlier releases. The way to get there is upgrade rather than update alone. 
For example, patching alone won't get you zfs root support nor branded 
containers. You are running a really old version of Solaris 10; much has 
changed for the better since that release.
Note that LU will preserve all your configuration information.

Ultimately what determines which release you're on is the contents of 
/etc/release. Patching won't change that (don't hack it). Upgrade will. The 
uname command will tell you which kernel you're running. Upgrading will change 
the result so will patching.



From: Auleta, Michael [mailto:michael_aul...@condenast.com]
Sent: Monday, August 30, 2010 11:44 AM
To: Hudes, Dana; veritas-ha@mailman.eng.auburn.edu
Subject: RE: Symantec CFS & OS Update


We're not looking for a feature update.  We need to be at a minimum Solaris 
release for a software upgrade, which we currently are not at.


From: Hudes, Dana [mailto:hud...@hra.nyc.gov]
Sent: Monday, August 30, 2010 10:57 AM
To: Auleta, Michael; veritas-ha@mailman.eng.auburn.edu
Subject: RE: Symantec CFS & OS Update

First off, you can't get feature updates by using the Solaris patch clusters or 
update connection. In order to get to update 8, you need to install and patch 
it. This is an activity best handled with Live Upgrade: first you load the new 
update into the Alternate BE, then you manually invoke patchadd -R on the ABE. 
Note: LU has a certain minimal patch set, available as a separate .zip download.

Secondly, yes you fail over each node. When you take it to single user mode the 
cluster will failover the service groups to other nodes in the cluster. Note 
that the node can't rejoin the cluster until the cluster is updated -- that is, 
your first node will run on it's own until you have a second at which time 
you've got a cluster again except you have two clusters. I'm not sure what 
happens to the service groups on the last node: they have nowhere to go.



From: veritas-ha-boun...@mailman.eng.auburn.edu 
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Auleta, Michael
Sent: Monday, August 30, 2010 9:41 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] Symantec CFS & OS Update

We've been given a task to update our OS level on some of our Symantec Cluster 
File System servers from Solaris 10 11/06 s10s_u3wos_10 SPARC to Solaris 10 
10/09 s10s_u8wos_08a SPARC using the Solaris Update patch clusters.  Does this 
need to be done simultaneously on all nodes in the cluster or can it be done on 
each node individually, failing over in the process?

Thanks -

Mike

Mike Auleta

UNIX Administrator

Conde Nast Publications

(302) 830-4688

michael_aul...@condenast.com


This e-mail, including attachments, is intended for the person(s) or company 
named and may contain confidential and/or legally privileged information. 
Unauthorized disclosure, copying or use of this information may be unlawful and 
is prohibited. If you are not the intended recipient, please delete this 
message and notify the sender.



This e-mail, including attachments, is intended for the person(s) or company 
named and may contain confidential and/or legally privileged information. 
Unauthorized disclosure, copying or use of this information may be unlawful and 
is prohibited. If you are not the intended recipient, please delete this 
message and notify the sender.
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] Symantec CFS & OS Update

[Hudes, Dana]

First off, you can't get feature updates by using the Solaris patch clusters or 
update connection. In order to get to update 8, you need to install and patch 
it. This is an activity best handled with Live Upgrade: first you load the new 
update into the Alternate BE, then you manually invoke patchadd -R on the ABE. 
Note: LU has a certain minimal patch set, available as a separate .zip download.

Secondly, yes you fail over each node. When you take it to single user mode the 
cluster will failover the service groups to other nodes in the cluster. Note 
that the node can't rejoin the cluster until the cluster is updated -- that is, 
your first node will run on it's own until you have a second at which time 
you've got a cluster again except you have two clusters. I'm not sure what 
happens to the service groups on the last node: they have nowhere to go.



From: veritas-ha-boun...@mailman.eng.auburn.edu 
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Auleta, Michael
Sent: Monday, August 30, 2010 9:41 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] Symantec CFS & OS Update


We've been given a task to update our OS level on some of our Symantec Cluster 
File System servers from Solaris 10 11/06 s10s_u3wos_10 SPARC to Solaris 10 
10/09 s10s_u8wos_08a SPARC using the Solaris Update patch clusters.  Does this 
need to be done simultaneously on all nodes in the cluster or can it be done on 
each node individually, failing over in the process?

Thanks -

Mike

Mike Auleta

UNIX Administrator

Conde Nast Publications

(302) 830-4688

michael_aul...@condenast.com



This e-mail, including attachments, is intended for the person(s) or company 
named and may contain confidential and/or legally privileged information. 
Unauthorized disclosure, copying or use of this information may be unlawful and 
is prohibited. If you are not the intended recipient, please delete this 
message and notify the sender.
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] Application Agent Zone Aware?

[Hudes, Dana]

I don't know the specifics of your issue here but in the global zone you
can see all the processes in all the zones. If there's a process you're
looking for which runs in multiple zones, you would of course need to
specify that.
Note that ps has an optional argument to do just that: -z zonename. So
you can have a script which does `ps -eafz myzone|grep myprocess`



=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of
pol.barthel...@skynet.be
Sent: Monday, May 18, 2009 1:29 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] Application Agent Zone Aware?

Hi,
Is anybody already try to use the Application Agent for monitoring the 
process inside a Solaris Zone On VCS 5MP3 ?
It seems that the containername is defined by not passed as argument on 
the parameter list !

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] LLT heartbeat redundancy

[Hudes, Dana]

I don't care what tricks Linux plays or what they call it. From a
network perspective, true bonding requires connection to the same
switch/router and is done at the link layer. You don't have 2 IP
interfaces, you have one. The bits go out round-robin. It requires
support by the link partner/peer (i.e., you could do it with multiple
crossover connections between two hosts which have the appropriate
drivers).

Solaris IPMP supports both active/active and active/passive (at least as
of Solaris 10).

http://docs.sun.com/app/docs/doc/816-4554/eobra?l=en&a=view&q=ipmp

Note that you can configure multiple VLANs into an IPMP group on one
interface. This doesn't give you any failover/failback capability: if
the link peer goes away, your link is down.

With active/active, you can have IPMP load spreading. This is only
effective with multiple IP destinations (even if those multiple IP
destinations are logical interfaces on one NIC on one host). 

IPMP groups are strictly the same media type but you can (and I have)
have a copper 100baseT port in the same group as a 1000baseF port:
they're both Ethernet. This does not work to backup an ATM interface
with an Ethernet interface etc. (I'm not sure if you could backup a LANE
interface with a classical IP-over-ATM interface and I haven't any ATM
switches to try it with these days).

Since this is an IP-level redundancy and LLT doesn't use IP it's not
going to help VCS.

IPMP is a replacement / successor to Sun Enterprise Alternate Pathing
(and is incompatible with it). In short, AP was for the Enterprise 1
only and provided a means of rerouting the connection to an HBA (whether
for storage or network). It is replaced by IPMP and MPXIO (which is
better than Veritas DMP but only in Solaris 10+).

Bonding isn't really something I expect to see in an Ethernet
environment but perhaps that's because I used to do it in an ATM
environment years ago. I'll have to look into what modern Ethernet LANs
do in this regard.


=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: Imri Zvik [mailto:im...@inter.net.il] 
Sent: Tuesday, May 12, 2009 9:54 PM
To: Hudes, Dana; veritas-ha@mailman.eng.auburn.edu
Subject: RE: [Veritas-ha] LLT heartbeat redundancy

Hi Dana,

We were talking about Linux bonding compared to Solaris IPMP.
While Solaris link aggregation (apparently) cannot do active/backup,
Linux
can, and therefore in Linux you can put each link on a separate switch
(http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documen
tati
on/networking/bonding.txt).
The whole point of the discussion was how to take the level of
redundancy
you get for LLT in Linux by using bonding to Solaris by using pure LLT
level
solution instead of counting on OS specific solutions (As IPMP doesn't
actually create a logical interface, LLT cannot use it).


-Original Message-
From: Hudes, Dana [mailto:hud...@hra.nyc.gov] 
Sent: Tuesday, May 12, 2009 11:28 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

Bonding is combining multiple links into one virtual circuit. It isn't
usually visible to the OS. IPMP is a bit different. While the result is
similar, it's a question of at what level of the tcp/ip stack the
combination is done. Bonding is at the media (MAC) layer from an IP
perspective (though the OSI model breaks the layers down differently).
IPMP is at the network layer. 

If the combined connections have individual IP addresses, that's
multi-path not bonding. 

There are implications here beyond clustering, including the switch and
the router as well as how the increase in bandwidth (if both links are
active at once) is achieved.  More usual is the use of IPMP to provide
standby links: each link has its own IP address and there is an IPMP IP
address. Remote hosts use the IPMP address. Often, you will have a
primary link which is higher speed / larger bandwidth than the secondary
(e.g. gigabit primary and 100 megabit secondary).

If you are bonding you must go to the same switch with both links. This
provides protection, in the form of degradation of capacity, against
port failure on either end of a given path or cable failure of a given
path. It does not protect you against switch failure.

IPMP, when done properly, has two paths each going to a separate switch.
This protects against everything that bonding does while also protecting
against switch failure. In the case of switch failure, the standby port
becomes active and ARP answers for the virtual IP on that port. The
routing protocol, which hopefully is OSPF, quickly redirects the traffic
to the new port and you don't even lose your TCP connection due to
retransmit (some UDP packets inevitably are lost; an application
protocol may have it's own retransmit timer but that's not UDP's
bus

Re: [Veritas-ha] LLT heartbeat redundancy

[Hudes, Dana]

Bonding is combining multiple links into one virtual circuit. It isn't
usually visible to the OS. IPMP is a bit different. While the result is
similar, it's a question of at what level of the tcp/ip stack the
combination is done. Bonding is at the media (MAC) layer from an IP
perspective (though the OSI model breaks the layers down differently).
IPMP is at the network layer. 

If the combined connections have individual IP addresses, that's
multi-path not bonding. 

There are implications here beyond clustering, including the switch and
the router as well as how the increase in bandwidth (if both links are
active at once) is achieved.  More usual is the use of IPMP to provide
standby links: each link has its own IP address and there is an IPMP IP
address. Remote hosts use the IPMP address. Often, you will have a
primary link which is higher speed / larger bandwidth than the secondary
(e.g. gigabit primary and 100 megabit secondary).

If you are bonding you must go to the same switch with both links. This
provides protection, in the form of degradation of capacity, against
port failure on either end of a given path or cable failure of a given
path. It does not protect you against switch failure.

IPMP, when done properly, has two paths each going to a separate switch.
This protects against everything that bonding does while also protecting
against switch failure. In the case of switch failure, the standby port
becomes active and ARP answers for the virtual IP on that port. The
routing protocol, which hopefully is OSPF, quickly redirects the traffic
to the new port and you don't even lose your TCP connection due to
retransmit (some UDP packets inevitably are lost; an application
protocol may have it's own retransmit timer but that's not UDP's
business).



=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding
> would remove the ability to discriminate between a link and a node
> failure.

I didn't understand this one - With bonding I can maintain full mesh 
topology - No matter which one of the links fails, if a node still has
at 
least one active link, LLT will still be able to see all the other
nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,
> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work
:)
I'm just saying that the cluster could be more redundant if it wasn't
designed 
that way :)

> If you have issues with port or cable failures, add a low pri
connection
> on a third network.



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] Zpool agent not functioning

[Hudes, Dana]

Yes you can have a mountpoint for snapshots.  Specifically, what you're
after is the visibility of the .zfs directory. This is controlled by the
"snapdir" property of the filesystem of which you took a snapshot. Each
snapshot is accessed within the .zfs directory of the filesystem root.

 

Let's say you have a pool named tank and a filesystem named hatch, and
to make things really interesting hatch is mounted under /export.  If
you do a zfs -l name,mountpoint you get

tank/hatch /export/hatch

 

Now you take a snapshot  and again 15 minutes later:

zfs snapshot tank/ha...@today1400



zfs snapshot tank/ha...@today1415

 

Then you want to see the snapshots in the filesystem so type

 

zfs set snapdir=visible tank/hatch

 

if you look in /export/hatch/.zfs/snapshot you will see 

today1400

today1415

 

(each of which is a directory).

 

=

Dana Hudes

UNIX and Imaging group

NYC-HRA MIS

+1 718 510 8586

Nextel:  172*26*16684

=



From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of
Anderson, Ryan C (US SSA)
Sent: Wednesday, March 25, 2009 2:18 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] Zpool agent not functioning

 

I am using the Zpool agent, and it was working fine in 4.1MP2 (with the
patch that added it), when it appears to have been a script agent. In
5.0MP3RP1 I just upgraded to (the agent is a binary now), its not
working, and it appears to be because I have ZFS snapshots. From
engine_A.log:

 

2009/03/25 13:12:05 VCS WARNING V-16-10001-20004 (testfs02)
Zpool:zVaultPool:monitor:Warning: The filesystem
vaultpool/vaul...@09_feb_18 with mountpoint - is not mounted.
Administrative action may be required

 

It looks like it expects a mountpoint for snapshots, which I'm not sure
is even possible. Anyone know a way around this?

 

RCA

--

UNIX Administrator, BAE Systems EIT
desk 763-572-6684  mobile 612-419-9362

 

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] VCS & Solaris Containers (Zones)

[Hudes, Dana]

Note that you can configure and install a zone on a host but set
autoboot=false in the configuration, letting VCS manage zone boot in an
active/passive cluster.  There are two approaches to zoneroot here:

1)Shared storage and rely on upgrade-on-attach (you can't downgrade
and watch out for the bad_patches issue for which there is a patch).
This way the disk group or zpool is only on one node at a time. Attempts
to boot the zone where the zoneroot isn't imported will fail (e.g. when
applying patches or installing packages to all zones) but that's ok
because you're going to patch nodes one at a time.

2)Zoneroot on 'local' storage (presumably the 'root disks' in the
machine), with perhaps logs on a shared disk (or not, you can argue it
both ways). This avoids any reliance on having the zoneroot imported and
also dodges the upgrade-on-attach - but then you have to re-patch the
zone on each node (note implications here: patching a node will boot all
bootable zones and patch them).

 

 

 

=

Dana Hudes

UNIX and Imaging group

NYC-HRA MIS

+1 718 510 8586

Nextel:  172*26*16684

=



From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Auleta,
Michael
Sent: Thursday, March 05, 2009 11:36 AM
To: Eric Hennessey; Veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] VCS & Solaris Containers (Zones)

 

Someone I work with was under the impression that VCS could run within a
zone, hence my question.  Now my new question, I have a server with an
app running in the global zone currently managed by VCS.  Is it possible
to move that to a non-global zone and manage that through VCS without
re-installing everything?

 



From: Eric Hennessey [mailto:eric_hennes...@symantec.com] 
Sent: Thursday, March 05, 2009 11:31 AM
To: Auleta, Michael; Veritas-ha@mailman.eng.auburn.edu
Subject: RE: [Veritas-ha] VCS & Solaris Containers (Zones)

Will VCS be managing the non-global zone so that it runs on either host?
If so, the zone needs to be configured on each host.  If the non-global
zone will only be running on one of the servers independent of the
cluster, then you're fine.

 

From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Auleta,
Michael
Sent: Friday, February 13, 2009 3:19 PM
To: Veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] VCS & Solaris Containers (Zones)

 

I've been tasked with rebuilding a server that is currently clustered
with two other nodes using VCS 4.1MP1 and creating two zones on it.  The
tricky part is that the target environment will (should) have only one
of the zones as part of the cluster.  The other servers in the cluster
do not currently have any zones on them.  Is this do-able?

Mike Auleta 
UNIX Administrator 
Conde Nast Publications 
(302) 830-4688 
michael_aul...@condenast.com 

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

[Veritas-ha] clustering solaris 10+ zones

[Hudes, Dana]

While at one level one can treat a zone as any other host and define the
nic and so forth so that VCS is monitoring the content of the zone, what
about just running VCS at the global zone level? Then you would monitor
each nonglobal zone as a resource.  Obviously you would define
dependencies such as NIC that the zone uses. IF the physical NIC shared
by a swarm of ngzs fails, your cluster is going to have a LOT of
failover activity at once...but that's true with working from inside the
zone too.

 

I can see issues with applications failing. It depends why...if its
shared storage is unavailable, failover is unlikely to help unless it's
a SAN HBA (or any other component of the connection to the switch)
issue. IF the Hitachi SAN controller goes down on both paths, your
entire cluster dies anyway (and how to tell it's the Hitachi not the
switch port? All you can see is that the path isn't available I believe
that luxadm -e port shows "NOT CONNECTED" regardless of whether it's a
local or remote issue).

 

 

Am I going to end up just using VCS to monitor child zone processes from
the global zone?

 

Any comments welcome, esp. comparisons (favorable or otherwise) to
SunCluster.

 

=

Dana Hudes

UNIX and Imaging group

NYC-HRA MIS

+1 718 510 8586

Nextel:  172*26*16684

=

 

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] Solaris 10 U5 Update

[Hudes, Dana]

I've got a machine with both SF5 and NBU6.5master on Solaris 10 u5 with
all the latest patches. Works fine. Please note that is not just
10_Recommended its whatever update connection's analysis indicates is
applicable.  You'll definitely need to apply all the Veritas patches but
UC should get and apply those for you (this assumes you have a sun
support contract such that you can use update connection to get all
patches).

 

When I went to 10u5 from previous versions of 10 I used Live Upgrade. I
also use LU for Veritas upgrades.

 

 

=

Dana Hudes

UNIX and Imaging group

NYC-HRA MIS

+1 718 510 8586

Nextel:  172*26*16684

=

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Goutham
N
Sent: Tuesday, June 17, 2008 1:36 AM
To: [EMAIL PROTECTED];
veritas-ha@mailman.eng.auburn.edu; [EMAIL PROTECTED]
Subject: [Veritas-ha] Solaris 10 U5 Update

 

 

Hi,

 

I am going to use Veritas Storage Foundation 5.x product in Solaris 10
U5 update. Will there be any compatability report available in

a place who would have already tested VSF 5.x in Solaris 10 U5 update on
SPARC and X86.  Pls advice with your answers.


N. Gowthaman 

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] VSC5, multiple Oracle10g fail-over instances

[Hudes, Dana]

I disagree. Three installations of binaries per cluster at most:

- production

- test 

- development

 

You have separate test and development because test is also for testing
the DBMS rather than the application. The development installation is
shared between the application developers and the application testers.
The developers don't upgrade or patch until application test is
complete, otherwise they may find themselves unable to reproduce (and
therefore fix) a problem found in test.

 

 

=

Dana Hudes

UNIX and Imaging group

NYC-HRA MIS

+1 718 510 8586

Nextel:  172*26*16684

=

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sayek,
Ogan
Sent: Wednesday, May 28, 2008 10:40 AM
To: Andrey Dmitriev; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] VSC5, multiple Oracle10g fail-over instances

 

I prefer to have binaries on the each host and sometimes per instance...
It will make patching a lot easier. You can apply the patch on the
passive node then failover run the post scripts and you are done as
opposed to having the DB down throughout the whole process and install
new binaries every time you need patches.  If you have DBAs that forget
to install patches on all nodes, I'd just fire them!!! People need to
understand the environment they are working on before they start
applying patches.  Force them to use deployment plans. 

 

 

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrey
Dmitriev
Sent: Wednesday, May 28, 2008 10:29 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] VSC5, multiple Oracle10g fail-over instances

 

My preferred method is to have one set of binaries 'per VCS group'. So
if you have a group per oracle instance, then you need dedicated
binaries per instance, if not, then have only one. If you need to
upgrade one of the db's, just install a set of binaries in parallel
(e.g. $ORACLE_BASE/product/9.2.0; $ORACLE_BASE/product/10.2.0 

  

I do not prefer to ever have binaries on the host (not shared storage),
for reasons mentioned below (can accidentally bring up db on a
mispatched host). 

  

-a

  _  

   From: John Cronin [mailto:[EMAIL PROTECTED] 

  

John Cronin wrote:

> It should be possible to use one set of Oracle binaries for multiple
> Oracle instances, I think - somebody please correct me if I am wrong.
> Unless it was a very strange situation, you would almost certainly
> need to have one copy of the identical binaries in identical locations
> on each of the three nodes though (or one copy on NFS, or a cluster
> filesystem that was globally accessible), so that really wouldn't be
> one copy of Oracle binaries, I guess.
>
> That said, I have generally not done that for the following reasons:
>
> 1) Disk space keeps getting cheaper and the binaries don't take up
> that much space (relatively speaking).
>
> 2) People virtually always forget to make changes (e.g. patching) to
> all three nodes equally - they patch one, or something like that, and
> they always get out of sync.  For this reason I generally prefer the
> binaries on shared storage, failing over with the data, but there are
> valid reasons not to do it this way too.
>
> 3) Someday someone might want upgrade for one of the instances, but
> not the others.  At that point you have the possibility of some
> screwing up one or more of the instances you didn't want to upgrade.  

  

  

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] [Veritas-vx] Storage Foundation (HA) on Solaris x86 systems

[Hudes, Dana]

If you have your data on CDS volumes that will make life simpler for
SPARC->x86.
If you are going from an old version such as 3.5 where you don't have
CDS then I would make new volumes and filesystems. I would send all data
with ncftp (because it will send a whole tree recursively; you could
also pull with wget if you have Apache set up on the source machine). I
am not really sure if VVR handles SPARC->x86 translation.


=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim
Kirby
Sent: Friday, March 28, 2008 1:52 PM
To: [EMAIL PROTECTED]; veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-vx] Storage Foundation (HA) on Solaris x86 systems

I am curious to know what sort of experience there might be out there
moving from Solaris on Sparc to Solaris on x86 with Veritas products;
my particular interest is an HA (VCS) cluster that is currently sparc
based and could stand an update - I'm less concerned about the VCS part
than the filesystem part; hardware wise the x86 option has a lot going
for it on paper...

But that's "on paper" and has little to do with reality. I'll happily
take comments offline for those who don't wish to opinionate in public.

I'll also take any comments on the success of running on the x86
platform
regardless of migration issues. The sparc systems have been really
solid...

Thanks

Tim
-- 
Tim Kirby   651-605-9074
[EMAIL PROTECTED]   Cray Inc. Information Systems


___
Veritas-vx maillist  -  [EMAIL PROTECTED]
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] installing VCS when local zones already created

[Hudes, Dana]

Even if Veritas are demanding that the zones go away you can do this
non-destructively. Shutdown the zones and move their .xml config files
in /etc/zones to a new name. When done move them back.

 

 

=

Dana Hudes

UNIX and Imaging group

NYC-HRA MIS

+1 718 510 8586

Nextel:  172*26*16684

=

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of VITALE,
CATHERINE F (CATHY), ATTSI
Sent: Tuesday, December 18, 2007 4:54 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] installing VCS when local zones already created

 

I have a couple of solaris 10 servers that already have some full root
local zones on them. A co-worker of mine says I must remove the zones in
order to run installvcs (5.0). Not sure why - something about not all
the packages get installed properly. Maybe scripts don't use -G option?
I don't see it documented in the install guide or release notes.

 

Can anyone explain what the issue may be?

 

If true, is there any thing I can do to fool the vcs installer without
wiping out the zones?

 

thanks,

 

Cathy

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] Use of ZFS and Veritas Cluster Server

[Hudes, Dana]

I don't know anything specific but it sounds like you're looking to have
shared storage between cluster nodes. The first issue is how you get the
physical storage shared -- perhaps you zone (in SAN terms) the LUN to
multiple machines and rely on the hosts to sort out access. In any case,
as I see it your ZFS plans have to isolate the datasets for a failover
group (perhaps a particular zone) into a particular zpool. Then your
failover process has to take the zone down (or acts on the zone going
down, either way) and then explicitly deport the zpool. The sequence is
important: if the delegated dataset is still in use you can't deport the
zpool. The online procedure is to first explicitly import the zpool
before bringing up the zone. 

=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nathan
Dietsch
Sent: Sunday, November 04, 2007 1:58 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] Use of ZFS and Veritas Cluster Server

Hello All,

Has anyone used ZFS as part of a Veritas Cluster Server
failover-cluster?

I am currently looking at a solution where Solaris Zones are being 
considered as a virtualisation solution and the combination of Zones and

ZFS looks promising. The chosen high-availability software in this 
organisation is VCS and I am looking at the possibility of combining 
Zones/ZFS with VCS to provide DR. Please note that Sun Cluster is not 
being considered at the moment as it is not supported within the 
organisation.

I am aware that Zones have been integrated with VCS since version 4.1, 
but I am interested in the experiences of people who have integrated ZFS

with VCS.

I understand that ZFS competes directly with storage foundation and that

Symantec may not be overly concerned about supporting ZFS.

Any input would be most appreciated.

Kind Regards,

Nathan Dietsch
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Re: [Veritas-ha] VxVM 4.1: Breaking mirrored root disks

[Hudes, Dana]

You have to unencapsulate the mirror you brokeoff. Bsically disable veritas 
init scripts on it and comment out veritas entries in /etc/system
--
Sent from my BlackBerry Wireless Device


-Original Message-
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: 'veritas-ha@mailman.eng.auburn.edu' 
Sent: Thu Jul 26 02:08:27 2007
Subject: [Veritas-ha] VxVM 4.1: Breaking mirrored root disks

Hi All,

 

We have our root disks mirrored and want to be able to break the mirror to 
upgrade the primary root disk only. The thinking is that if the upgrade goes 
badly that we can always revert back to the secondary rootmirror disk. The 
complication is that we cannot physically remove the secondary boot disk 
(rootmirror).

 

Are their veritas commands that can break the mirror of the rootdisks, but 
still allow me to boot from the secondary boot disk if things go badly. I have 
tried the following commands to break the mirror:

 

# vxassist [-g diskgroup] remove mirror volume

# vxplex -g diskgroup dis volume-02

# vxedit -g diskgroup -r rm volume-02

 

The above commands allow me to break the mirror but do not allow me to boot 
from the secondary boot disk as the rootvol-02 plex is disabled.  When I boot 
from the secondary I get:

 

Jul 26 06:06:01 vxvm:vxconfigd: V-5-1-1049 System boot disk does not have a 
valid rootvol plex

Jul 26 06:06:01 vxvm:vxconfigd: Please boot from one of the following disks:

Jul 26 06:06:01 vxvm:vxconfigd: DISK MEDIA  DEVICE  BOOT 
COMMAND

Jul 26 06:06:01 vxvm:vxconfigd: dg-boot01   Disk_1  boot 
vx-dg-boot01 

Jul 26 06:06:01 vxvm:vxconfigd: V-5-1-8259 System startup failed

syncing file systems... done

Program terminated

{3} ok

 

I have done this thing in the past by physically removing the secondary root 
disk, but we need to do this upgrade remotely. Is there a way that I can break 
the mirror but still be able to boot from the secondary without removing any 
disks?

 

Any help or suggestions would be appreciated.

 

Thanks,

 

Rick

 

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha