Re: [Veritas-ha] Extend vxfs block size 1k disk layout 7 beyond 4TB
This is probably because the file system is almost full. Before the file
systems expands, it needs free space for the meta-data by growing the volume
500 mb, it provides plenty of meta-data space for a larger grow.
You could then do a defray fsadm –E and –D will report on degree of
fragmentations of extents and data. Fsadm –e –d will perform the defrag.
From: Everett56 everet...@verizon.netmailto:everet...@verizon.net
Date: Friday, December 14, 2012 7:15 AM
To: Anatoly Pugachev mator...@gmail.commailto:mator...@gmail.com
Cc:
veritas...@mailman.eng.auburn.edumailto:veritas...@mailman.eng.auburn.edu
veritas...@mailman.eng.auburn.edumailto:veritas...@mailman.eng.auburn.edu,
veritas-vx-boun...@mailman.eng.auburn.edumailto:veritas-vx-boun...@mailman.eng.auburn.edu
veritas-vx-boun...@mailman.eng.auburn.edumailto:veritas-vx-boun...@mailman.eng.auburn.edu,
veritas-ha@mailman.eng.auburn.edumailto:veritas-ha@mailman.eng.auburn.edu
veritas-ha@mailman.eng.auburn.edumailto:veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] Extend vxfs block size 1k disk layout 7 beyond 4TB
Going from 4TB to 6TB is a big increase. When I have had a similar problem in
the past, I found it would work if I increased in a couple small increments
first, then on to the larger size. For instance add +1G, then +4G, then the
remainder to get to the size you desire. If the first increase of a 1G add
fails, try 500m instead.
I used to know the reason behind this but I've forgotten it now. I know it
works for me though.
On Dec 13, 2012, at 11:25 PM, Anatoly Pugachev
mator...@gmail.commailto:mator...@gmail.com wrote:
Hi!
- do you have some free space on FS?
- do you have log on this volume? I'm not sure, but if log segment (plex) is
too small, it could block FS extension.
On Fri, Dec 14, 2012 at 6:47 AM, Boddula, Shashi Kanth (HP-SW-LIT)
shashi-kanth.bodd...@hp.commailto:shashi-kanth.bodd...@hp.com wrote:
HP-UX 11iv3 SF 5.0.1
I have vxfs version disk layout 7 on a vxfs file system.
#fstyp -v /dev/vx/rdsk/ftp_dg/ftp_vol | grep version | awk '{print $2}'
7
I am trying to increase the size of a vxfs file system from 4TB to 6TB. The
vxresize reports the bellow error if i try to extend the file system.
UX:vxfs extendfs: ERROR: V-3-23773: With existing block size 1K, can not extend
fs beyond 6442450687 sectors (6 TB)
But as per the documentation with 1K block size and disk layout 7, it can go up
to 32 TB.
How to extend the filesystem in this scenario?. Someone please suggest.
___
Veritas-ha maillist -
Veritas-ha@mailman.eng.auburn.edumailto: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] FileStore interconnect
The minimum configuration for FileStore is 4 NICs, 2 for private interconnect (including a private IP for PXE boot of the second node to get it installed) and 2 for the client network for access. On 2/23/12 11:10 AM, Colin Yemm colin.y...@gmail.com wrote: Sergey, Two separate VLANs (instead of crossover cables) will work fine. Just make sure that the VLANs are run from two different switches so you eliminate the SPOF. I also usually recommend that if you have ANY chance of moving from a 2 to a 3+ node cluster, spec switches for the heartbeats from the outset. C ___ 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] MultiNICB attribute question
The section of the Bundled Agents Ref Guide that shows Failback has a note
above it that these are optional for Base mode. You are using MPathd mode, so
Failback setting is ignored. Your issue is with Mpathd, not MNICB
nfs10 in.mpathd[9033]: [ID 620804 daemon.error] Successfully failed back to NIC
e1000g0
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Mark Schipper
Sent: Monday, October 18, 2010 12:54 PM
To: Christian Gerbrandt; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] MultiNICB attribute question
Hmmm...
That's what I would have expected, but my cluster is clearly set:
Failback = 0
And I had failback happen 4 times (IP switched interfaces 8 times) while a
switch port was flapping a few days ago. Would have been desirable for the IP's
to stay on the secondary NIC.
Here's proof of failback:
Oct 14 20:44:43 nfs10 in.mpathd[9033]: [ID 594170 daemon.error] NIC failure
detected on e1000g0 of group mnic_pcsnfs3
Oct 14 20:44:43 nfs10 in.mpathd[9033]: [ID 832587 daemon.error] Successfully
failed over from NIC e1000g0 to NIC e1000g2
Oct 14 20:45:03 nfs10 in.mpathd[9033]: [ID 299542 daemon.error] NIC repair
detected on e1000g0 of group mnic_pcsnfs3
Oct 14 20:45:03 nfs10 in.mpathd[9033]: [ID 620804 daemon.error] Successfully
failed back to NIC e1000g0
And proof that my VCS config uses mpathd:
MultiNICB mnic_pcsnfs3 (
UseMpathd = 1
Device @nfs09 = { e1000g0 = 0, e1000g2 = 1 }
Device @nfs10 = { e1000g0 = 0, e1000g2 = 1 }
Device @nfs11 = { e1000g0 = 0, e1000g2 = 1 }
)
Does this mean Failback = 0 was ignored or over-ridden?
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Christian
Gerbrandt
Sent: Monday, October 18, 2010 8:56 AM
To: Mark Schipper; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] MultiNICB attribute question
It is the opposite way:
Table 3-13 Optional attributes for Base mode
Optional
attribute Description
Failback If the value of the attribute is 1, the virtual IP addresses
are failed back to the original physical interface
whenever possible. A value of 0 disables this behavior.
Type and dimension: integer-scalar
Default: 0
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Mark Schipper
Sent: 18 October 2010 16:40
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] MultiNICB attribute question
Gang,
The default behavior of MultiNICB is to switch back to the primary interface
if/when link is restored. Documentation I have read confirms this. And since
the Failover attribute defaults to 0:
[r...@db09:/]# haattr -display MultiNICB | grep Failback
Failback [integer/scalar]= 0
I would like to verify that setting:
Failback = 1
will prevent an interface failback when the primary NIC link is restored.
Thanks
...
Mark Schipper | UNIX Engineer
+1 (408) 688-3196 office | +1 (831) 325-9882 mobile
Syniverse Technologies | We make mobile work.
mark.schip...@syniverse.commailto:email.addr...@syniverse.com |
www.syniverse.comhttp://www.syniverse.com/
...
___
Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] I/O Fencing non-CFS
IO Fencing works with VCS. Even without CFS/RAC it is the best protection against split-brain. You CAN import a DG on multiple systems by using vxdg -C import dg to clear the name in the private region. Alternatives include the preonline_ipc trigger (in sample_triggers, copy to triggers, rename preonline and enable PreOnline in service groups). Also link-lowpri. From: veritas-ha-boun...@mailman.eng.auburn.edu [mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Everett Henson Sent: Wednesday, October 13, 2010 11:04 AM To: 'veritas-ha@mailman.eng.auburn.edu' Subject: [Veritas-ha] I/O Fencing non-CFS Group, There has been a discussion in my workplace over the usefulness of I/O Fencing in the absence of CFS or Oracle RAC. The question is whether I/O Fencing is necessary when Standard Storage Foundation is being used. My understanding is that without CFS or RAC, only one node can have a Disk Group imported at a time, and even in the event of split brain, no two servers can have the same access to the same storage simultaneously. Any attempt by one server to import storage already imported on another server should result in a FAULT or an error. In all the documentation on Veritas I've read over the years, I/O Fencing is only mentioned in connection with shared storage, and never with standard SF. So, what is the consensus, does implementing I/O Fencing with Standard SF provide any advantage? Everett Henson 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 and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext. ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] I/O Fencing non-CFS
The server that had it imported would not notice the change.. Both servers can access the storage. If you didn't have link-lowpri, then bringing up the IP would probably stop the process as it got a ping on the other IP already running. From: veritas-ha-boun...@mailman.eng.auburn.edu [mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Everett Henson Sent: Wednesday, October 13, 2010 11:40 AM To: Gene Henriksen; 'veritas-ha@mailman.eng.auburn.edu' Subject: Re: [Veritas-ha] I/O Fencing non-CFS 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. 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? BTW, We are using two private interconnects as well as a link-lowpri already. From: Gene Henriksen [mailto:gene_henrik...@symantec.com] Sent: Wednesday, October 13, 2010 11:34 AM To: Everett Henson; 'veritas-ha@mailman.eng.auburn.edu' Subject: RE: I/O Fencing non-CFS IO Fencing works with VCS. Even without CFS/RAC it is the best protection against split-brain. You CAN import a DG on multiple systems by using vxdg -C import dg to clear the name in the private region. Alternatives include the preonline_ipc trigger (in sample_triggers, copy to triggers, rename preonline and enable PreOnline in service groups). Also link-lowpri. From: veritas-ha-boun...@mailman.eng.auburn.edu [mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Everett Henson Sent: Wednesday, October 13, 2010 11:04 AM To: 'veritas-ha@mailman.eng.auburn.edu' Subject: [Veritas-ha] I/O Fencing non-CFS Group, There has been a discussion in my workplace over the usefulness of I/O Fencing in the absence of CFS or Oracle RAC. The question is whether I/O Fencing is necessary when Standard Storage Foundation is being used. My understanding is that without CFS or RAC, only one node can have a Disk Group imported at a time, and even in the event of split brain, no two servers can have the same access to the same storage simultaneously. Any attempt by one server to import storage already imported on another server should result in a FAULT or an error. In all the documentation on Veritas I've read over the years, I/O Fencing is only mentioned in connection with shared storage, and never with standard SF. So, what is the consensus, does implementing I/O Fencing with Standard SF provide any advantage? Everett Henson 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 and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext. 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 and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext. ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] wac question and suggestion
Having taught Global Clustering and its predecessor, I would prefer to see WAC have the ability to failover from one IP to another or make multiple connections over 2 or 3 IPs for higher redundancy. Keep in mind that DR is not HA If the WAC loses the connection, you would get notification and can fix the problem or online SGs at the remote site as appropriate. From: veritas-ha-boun...@mailman.eng.auburn.edu [mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Pavel A Tsvetkov Sent: Wednesday, May 13, 2009 9:56 AM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] wac question and suggestion Hello all! Only WAC now ensures communication between clusters. But it is not always good. If WAC is broken it is still possible to use heartbeats (through SRDF ping or steward) but there is no other ways of starting service groups on remote cluster. I don't mean Auto failover option between clusters which is not recommended by Symantec, If steward could handle service group information between clusters . It could be really a useful thing! Kind regards, Pavel Tsvetkov ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] Linking Two Service Groups
First I think there is a difference in the 4.x and 5.x Agent framework on which the Agents are compiled, so I don't know if copying an agent from 5.0 to 4.x will work. Second, I don't know if it is legal from the perspective of the licensing (I am definitely not a lawyer). Third, you would have to install the 5.0 system and see the RemoteGroupAgent. Looking at a 5.0MP3 install, there are no online/offline/monitor scripts, they are compiled into the Agent. There is also a RemoteGroup.xml (something new in 5.0). Prior to the RemoteGroupAgent, the problem was solved by using ssh scripts and the Application Agent. From: veritas-ha-boun...@mailman.eng.auburn.edu [mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Jeffrey Cooper Sent: Wednesday, December 17, 2008 6:41 AM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] Linking Two Service Groups Dear Gene, I got a rough understanding of the RemoteGroup Agent and how is it working. Actually that's exactly what i need to resolve my problem. But as it is not easy to upgrade VCS 4.1 to 5.0 on my system, i'm wondering if importing RemoteGroup type in VCS 4.1 may work. For that purpose, i understand that for an agent to work in VCS, it needs its type imported in VCS system and the relying control scripts present as well. Actually, i have first imported RemoteGroup type from VCS simulator 5.0 into my VCS 4.1 platform, and now i have RemoteGroup type in my system. What i miss now is RemoteGroup Agent scripts that take online and offline the remote service group, i.e. i got an error that File /opt/VRTSvcs/bin/RemoteGroup/RemoteGroupAgent not found when i tried to probe my new RemoteGroup resource. My question is: does this resource work if i copy and paste RemoteGroupAgent script in the specified path with all necessary scripts of control of RemoteGroup, and where can i find these scripts? Any Help Will Be So Valued, Thanks Regards, Jeffrey Cooper. ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] VCS 5.0 MP1: issue probing disk-group !?
Can you put the SG info from main.cf in an email so we can see the configuration? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pascal Grostabussiat Sent: Tuesday, October 21, 2008 9:11 AM Cc: Veritas-ha@mailman.eng.auburn.edu Subject: Re: [Veritas-ha] VCS 5.0 MP1: issue probing disk-group !? To Jim, Scott and Gene. Jim Senicka wrote: Is the disk group agent running on the systems? Yes it is: root 16295 1 0 16:16:01 ? 1:29 /opt/VRTSvcs/bin/DiskGroup/DiskGroupAgent -type DiskGroup Has the cluster been started since you created the service group definition? Yes. I restarted VCS hopping it might somehow change something, but no. I am thinking about rebooting one server. Are all resources enabled in the service groups? Yes. I tried to disable them and re-enable them. But I come back to the same situation. Scott3, James wrote: Have you made sure the volumes are ENABLED ACTIVE? Can you send a vxprint on the group? Is it a shared group or a active/passive group? Also send a vxdg list. Enabled and active, yes. The disk-group is active/passive (to be mounted on one host at a time). bash-3.00# vxprint -l dba_DG Disk group: dba_DG Group:dba_DG info: dgid=1224062934.119.hostname version: 140 alignment: 8192 (bytes) detach-policy: global dg-fail-policy: dgdisable copies: nconfig=default nlog=default devices: max=32767 cur=3 minors: = 62000 cds=on bash-3.00# vxprint -g dba_DG TY NAME ASSOCKSTATE LENGTH PLOFFS STATETUTIL0 PUTIL0 dg dba_DG dba_DG ----- - dm dba_DG01 c0t216000C0FF87E774d10s2 - 525417536 - -- - v dba_archive fsgenENABLED 20971520 -ACTIVE - - pl dba_archive-01 dba_archive ENABLED 20971520 -ACTIVE - - sd dba_DG01-02 dba_archive-01 ENABLED 20971520 0 -- - v dba_data fsgenENABLED 104857600 - ACTIVE - - pl dba_data-01 dba_data ENABLED 104857600 - ACTIVE - - sd dba_DG01-03 dba_data-01 ENABLED 104857600 0 -- - v dba_redo fsgenENABLED 20971520 -ACTIVE - - pl dba_redo-01 dba_redo ENABLED 20971520 -ACTIVE - - sd dba_DG01-01 dba_redo-01 ENABLED 20971520 0-- - bash-3.00# vxdg list NAME STATE ID xxx_DG enabled,cds 1224062531.89.hostname xxx_DG enabled,cds 1224062634.101.hostname xxx_DG enabled,cds 1224062699.109.hostname dba_DG enabled,cds 1224062934.119.hostname xxx_DG enabled,cds 1224062443.81.hostname xxx_DGenabled,cds 1224062569.93.hostname xxx_DG enabled,cds 1224062672.105.hostname xxx_DG enabled,cds 1224062491.85.hostname Gene Henriksen wrote: If you have a ? in the GUI, then it cannot probe the resource on one system or the other. It will not import on either until it is probed on both. This is to avoid a concurrency violation. Yes. Fully agree. Hold the cursor on the resource and a pop-up box should show the status so you can see where it is not probed. Status is unkown on both server A and B. This could be due to one system having never seen the DG. Can you run vxdisk -o alldgs list and see the DG on both systems? I can import/deport that disk-group using vxdg without a problem bash-3.00# vxdisk -o alldgs list DEVICE TYPEDISK GROUPSTATUS c0t216000C0FF87E774d0s2 auto:none --online invalid c0t216000C0FF87E774d1s2 auto:cdsdiskxxx_DG01 xxx_DG online c0t216000C0FF87E774d2s2 auto:cdsdiskxxx_DG01xxx_DG online c0t216000C0FF87E774d3s2 auto:cdsdiskxxx_DG01xxx_DG online c0t216000C0FF87E774d4s2 auto:cdsdiskxxx_DG01 xxx_DGonline c0t216000C0FF87E774d5s2 auto:cdsdisk-(xxx_DG)online c0t216000C0FF87E774d6s2 auto:cdsdiskxxx_DG01xxx_DG online c0t216000C0FF87E774d7s2 auto:cdsdiskxxx_DG01xxx_DG online c0t216000C0FF87E774d8s2 auto:cdsdiskxxx_DG01 xxx_DG online c0t216000C0FF87E774d9s2 auto:cdsdisk-(xxx_DG) online c0t216000C0FF87E774d10s2 auto:cdsdiskdba_DG01 dba_DG online c2t0d0s2 auto:none --online invalid c2t2d0s2 auto:none --online invalid c2t3d0s2 auto:none --online invalid The other possibility is a typo in the DiskGroup resource attribute. Make sure it has no leading spaces, is the correct case (just like vxdisk list shows it. I thought about this and double-checked. Nothing. I recreated the resource and paid attention to such possibility, nothing. Regards, /Pascal ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] Adding A New LUN and Solaris
LUNs are really not cluster aware, clusters, through Storage Foundation, are LUN aware. Zone the LUN to be seen by both systems. Run devfsadm or the Solaris 10 equivalent if it has changed on both systems. You should now be able to see the LUN in the format command output. Run vxdctl enable on both systems. You should now see the disk in vxdisk list on both systems. You will need to initialize it from one system with vxdisksetup -I disk name You can add it to an existing Disk Group or use it for a new Disk Group. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hunter Sent: Wednesday, October 15, 2008 12:35 PM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] Adding A New LUN and Solaris Solaris 10 VxVM VCS 5 How do I add a new LUN to an existing 2 node cluster and make the LUN cluster aware? Thanks ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] Correcting the types.cf file
Out of curiosity, what is the difference between the good types.cf and what it saves? Did you manually edit the good types.cf to make changes? If you edited the types.cf, you could have added extra spaces or put in a setting that is already a default and these would get stripped out on a save. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Auleta, Michael Sent: Thursday, August 07, 2008 3:12 PM To: Manuel Braun; veritas-ha@mailman.eng.auburn.edu Subject: Re: [Veritas-ha] Correcting the types.cf file The simulator exibits the same behavior. Start the cluster Check the types.cf (-rw--- 1 root root 6348 Aug 7 14:55 types.cf) (correct) Run hacf -makerw Run hacf -dump -makero Check the types.cf (-rw--- 2 root root 6171 Aug 7 14:56 types.cf) (incorrect) I'm not sure it's actually reading the types.cf file I want to use. I can't find any other instances other than /etc/VRTSvcs/conf /opt/VRTScssim, and they're the correct size. What I actually think is happening is that the types.cf setting is being ignored in main.cf, but I don't know where the one that's being used is coming from. From: Manuel Braun [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2008 2:53 PM To: Auleta, Michael; veritas-ha@mailman.eng.auburn.edu Subject: RE: [Veritas-ha] Correcting the types.cf file Hi Mike, How about this: 1) hastop -local -force on the strange node 2) Move all files from the /etc/VRTSvcs/conf/config to a backup location 3) hastart on the strange node Regards Manuel From: Auleta, Michael [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. August 2008 20:43 To: Manuel Braun; veritas-ha@mailman.eng.auburn.edu Subject: RE: [Veritas-ha] Correcting the types.cf file I tried that previously (after your initial response). Same issue. From: Manuel Braun [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2008 2:28 PM To: Auleta, Michael; veritas-ha@mailman.eng.auburn.edu Subject: RE: [Veritas-ha] Correcting the types.cf file Hi Mike, I quickly tested this in a lab cluster. A non-existing or modified types.cf is overwritten in the REMOTE_BUILD phase on the joining node. Could you please try removing the types.cf before doing the hastart. Regards Manuel From: Auleta, Michael [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. August 2008 19:53 To: Manuel Braun; veritas-ha@mailman.eng.auburn.edu Subject: RE: [Veritas-ha] Correcting the types.cf file Still not working. I did the following: 1) hastop -all -force 2) copied the correct types.cf into /etc/VRTSvcs/conf/config 3) ran hastart on the good node 4) waited for resources to come on line 5) verified the types.cf had not changed 6) ran hastart on the other node 7) waited for resources to come on line the types.cf file is the old one again on the second node before running hastart node 1: [EMAIL PROTECTED]:/etc/VRTSvcs/conf/config mailto:[EMAIL PROTECTED]:/etc/VRTSvcs/conf/config ls -ltr total 722 -rw-r--r-- 1 root sys 244 Jul 11 2003 VRTSWebAppType.cf -r--r--r-- 1 root root6348 Nov 20 2007 types.cf.init41 -rw--- 2 root root1074 Nov 20 2007 OracleTypes.cf -rwx--x--x 1 root root 45695 Nov 20 2007 main.cmd.cvk -rw--- 1 root root 112046 Nov 20 2007 main.cmd -rw-r--r-- 1 root root5168 May 5 10:10 1 -rw--- 2 root root 51018 Jul 23 14:56 main.cf drwxr-xr-x 2 root root1536 Aug 6 14:53 bkups -rw--- 1 root root 51018 Aug 6 14:54 main.cf.2008080600 -rw--- 1 root root 51071 Aug 6 14:55 main.cf.new -rw--- 1 root root6171 Aug 6 14:58 types.cf.2008080600 -rw--- 2 root root6348 Aug 6 16:35 types.cf.previous -rw--- 2 root root6348 Aug 7 13:40 types.cf.07Aug2008.09.47.3 3 -rw--- 2 root root6348 Aug 7 13:40 types.cf node 2: [EMAIL PROTECTED]:/etc/VRTSvcs/conf/config mailto:[EMAIL PROTECTED]:/etc/VRTSvcs/conf/config ls -ltr total 248 -rw--- 1 root root6348 Aug 7 09:44 types.cf.previous -rw--- 1 root root1074 Aug 7 09:44 OracleTypes.cf -rw-r--r-- 1 root root 244 Aug 7 09:45 VRTSWebAppType.cf -rw--- 2 root root 51018 Aug 7 09:45 main.cf.07Aug2008.09.45.41 -rw--- 2 root root 51018 Aug 7 09:45 main.cf -rw--- 2 root root6348 Aug 7 13:40 types.cf.07Aug2008.09.45.41 -rw--- 2 root root6348 Aug 7 13:40 types.cf After running hastart node 1: [EMAIL PROTECTED]:/etc/VRTSvcs/conf/config mailto:[EMAIL PROTECTED]:/etc/VRTSvcs/conf/config hastart [EMAIL PROTECTED]:/etc/VRTSvcs/conf/config mailto:[EMAIL
Re: [Veritas-ha] clustering solaris 10+ zones
Have you read the information in the VCS Users Guide on Zones? There is a description of how to set it up. VCS runs in the global zone. Some resources have the ability to start processes or IP, for example, in a zone (these resources have a container name in the attributes. Resources such as NIC and DiskGroup are in the global zone. There is a Zone resource to start/stop and monitor the zone. So VCS can monitor the local zones and the processes and IPs within the zone. If a problem occurs in the zone, then VCS can failover the zone to another server. If you SAN fails, VCS is not able to help you. VCS will mark the Disk Group dgdisabled. This can be cleared manually by a deport and import. If the SAN fails there is no reason to failover. For very high availability you should have 2 HBAs, multiple SAN switches and data mirrored across arrays. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hudes, Dana Sent: Thursday, July 24, 2008 2:33 PM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] clustering solaris 10+ zones 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] Missing Files
Nothing is missing, that is all there should be. The fact that there is no online, offline, monitor or clean indicates they are built into the NotifierAgent binary. You will see the same on some others. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of i man Sent: Tuesday, July 22, 2008 12:08 PM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] Missing Files While trying to create a resource I see some files mising from the system. In /opt/VRTSvcs/bin/NotifierMngr directory... NotifierMngrAgent NotifierMngr.xml Could this be because of some incomplete installation ? or any particular component not installed on the system ? Ciao. ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] ClusterService Group
ClusterService is a group that belongs to the cluster itself. In most instances you will find it that way you describe. It also is a great place for the notifier resource. Normally it is not required. When using Global Clustering (connecting 2 or more clusters for wide area failover), the Wide Area Connector process is in the group along with its IP and NIC resource. CS has special properties above and beyond normal SGs. It cannot be frozen, is never autodisabled, and it can failover to a frozen system. I am not sure why you would put a NIC proxy in it. Perhaps you plan to put in the NIC and have other SGs use proxies to it. If so, you will not need the Phantom resource normally in a NIC only SG. The IP and web will bring the SG online so the Phantom is only required when the only resource is a NIC (since NIC is not able to bring a SG online by itself). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of i man Sent: Wednesday, June 25, 2008 8:09 AM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] ClusterService Group Hi, I know Cluster service group hosts vcsweb and webip agent but can somebody exactly explain what the use of Cluster service group. Would I be ble to shut this down for some maintenance operations/testing without affecting other service groups and vcs in whole ? Whats the affect on the system by shutdown of CSG ? I'm also planning to put an nic proxy group in clusterservice gorup , I hope this would not be a bad idea as currently only have vcsweb and webip. Ciao ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] ClusterService Group
No problem. In your case, shutting down CSG will stop notification. It
has no effect on VCS.
From: i man [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2008 8:53 AM
To: Gene Henriksen; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] ClusterService Group
Gene,
NIC proxy is for the notifier resource for a NIC in separate servie
group. What I want to achieve is something like below
group ClusterService (
SystemList = { = 1, = 2 }
UserStrGlobal =
[EMAIL PROTECTED]://XXX.XX.XX.XX:8443;[EMAIL PROTECTED]://XXX.XX.
XX.XX:8443;
AutoStartList = { , }
)
IP webip (
Device = enX
Address = XXX.XX.XX.XX
NetMask = XXX.XX.XX.XX
)
NotifierMngr snmp_notifier (
SnmpConsoles = { XXX = Information }
)
Proxy nicproxy (
Enabled = 0
TargetResName = XXX-XXX-XXX
)
VRTSWebApp VCSweb (
Critical = 0
AppName = vcs
InstallDir = /opt/VRTSweb/VERITAS
TimeForOnline = 5
)
VCSweb requires webip
snmp_notifier requires nicproxy
webip requires nicproxy
What I also wanted to know is the affect on the vcs running on the
system by the affect of shutting down CSG.
Ciao
On Wed, Jun 25, 2008 at 1:37 PM, Gene Henriksen
[EMAIL PROTECTED] wrote:
ClusterService is a group that belongs to the cluster itself. In most
instances you will find it that way you describe. It also is a great
place for the notifier resource. Normally it is not required. When using
Global Clustering (connecting 2 or more clusters for wide area
failover), the Wide Area Connector process is in the group along with
its IP and NIC resource.
CS has special properties above and beyond normal SGs. It cannot be
frozen, is never autodisabled, and it can failover to a frozen system.
I am not sure why you would put a NIC proxy in it. Perhaps you plan to
put in the NIC and have other SGs use proxies to it. If so, you will not
need the Phantom resource normally in a NIC only SG. The IP and web will
bring the SG online so the Phantom is only required when the only
resource is a NIC (since NIC is not able to bring a SG online by
itself).
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of i man
Sent: Wednesday, June 25, 2008 8:09 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] ClusterService Group
Hi,
I know Cluster service group hosts vcsweb and webip agent but can
somebody exactly explain what the use of Cluster service group.
Would I be ble to shut this down for some maintenance operations/testing
without affecting other service groups and vcs in whole ? Whats the
affect on the system by shutdown of CSG ?
I'm also planning to put an nic proxy group in clusterservice gorup , I
hope this would not be a bad idea as currently only have vcsweb and
webip.
Ciao
___
Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] .stale file
It indicates you did not close and save the cluster configuration after making modifications. It is a warning. If you close and save the config, it goes away. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of i man Sent: Tuesday, June 03, 2008 7:28 AM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] .stale file All, Had some queries regarding the .stale file present in the /etc/VRTSvcs/conf/config directory. I know that if the haagents are restarted with hastop -all -force and this file is present the cluster memebers could be in stale admin wait state. I have been deleting this file then hastop -all -force and then hastart on the the nodes. I do not want the service groups to go offline that's why -force. My query is what is the use of .stale ? Would hastart -force help to get nodes back if this file is present ? Is file deletion the only method to get the nodes back ? I noticed recently that when getting the cluster back, this way my clusters the information about the admin password. I thnk I'm doing something wrong.any help. Ciao. ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] .stale file
Putting the Notifier in the cluster service group also has an advantage because CSG is the first SG up and the hardest to kill, therefore in times of lots of problems you will get notification more so than if the service group you arbitrarily chose to use is faulted on all systems in the cluster, then notification is also down. You could create the CSG in one system, save the configuration, run hacf -cftocmd . in the /etc/VRTSvcs/conf/config directory, then edit the main.cmd (look toward the bottom) to find the commands to create the CSG and Notifier, make a script and modify to run on other clusters. From: John Cronin [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 10:45 AM To: i man Cc: Jim Senicka; Gene Henriksen; veritas-ha@mailman.eng.auburn.edu Subject: Re: [Veritas-ha] .stale file It would be no problem to create a Notifier resource in any arbitrary service group with the CLI. If I understand this correctly, what you are doing is shutting down VCS, and then editing main.cf to change the config? If this was for one or two clusters, it might be an OK way to do it, but if this is for hundreds of systems, it would be better to learn how to use the CLI and then script the changes. Also, what is the problem with putting the notifier in the ClusterService group? I can't see how putting it in another service group would provide you any particular benefit - the Notifier if going to do the same things no matter which service group it is in. Since it is a cluster wide service, it makes sense that it should be in the ClusterService group. As for using hastop -all -force, I tend to use it frequently on production systems when I am doing something that requires stopping the cluster, but does not require stopping the systems or the services running on those systems (e.g. patching or upgrading VCS, or reconfiguring GAB or LLT). However, I would not do this to accomplish something that can be done with CLI commands. -- John Cronin On 6/3/08, i man [EMAIL PROTECTED] wrote: Correct Jim, If this would have been a normal cluster service group I would loved to have done that. What I'm trying to obtain is creation of snmp notifier in a separate service group . Through GUI you cannot create it in your own service group but could only create it as a part of Clusterservicegroup. Not sure if this is achievable through CLI. Any suggestions ? On Tue, Jun 3, 2008 at 2:52 PM, Jim Senicka [EMAIL PROTECTED] wrote: Right. But that can also be done via CLI or GUI with the cluster running. From: i man [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 9:48 AM To: Jim Senicka Cc: Gene Henriksen; veritas-ha@mailman.eng.auburn.edu Subject: Re: [Veritas-ha] .stale file Jim, This is to update systems with some new service groups. This is not on a single system but rather large number of systems (100+) Also so many thanks to Gene and John for resolving my doubts. Ciao, On Tue, Jun 3, 2008 at 2:30 PM, Jim Senicka [EMAIL PROTECTED] wrote: Bigger question is what are you routinely using stop -force to accomplish? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gene Henriksen Sent: Tuesday, June 03, 2008 8:17 AM To: i man; veritas-ha@mailman.eng.auburn.edu Subject: Re: [Veritas-ha] .stale file It indicates you did not close and save the cluster configuration after making modifications. It is a warning. If you close and save the config, it goes away. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of i man Sent: Tuesday, June 03, 2008 7:28 AM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] .stale file All, Had some queries regarding the .stale file present in the /etc/VRTSvcs/conf/config directory. I know that if the haagents are restarted with hastop -all -force and this file is present the cluster memebers could be in stale admin wait state. I have been deleting this file then hastop -all -force and then hastart on the the nodes. I do not want the service groups to go offline that's why -force. My query is what is the use of .stale ? Would hastart -force help to get nodes back if this file is present ? Is file deletion the only method to get the nodes back ? I noticed recently that when getting the cluster back, this way my clusters the information about the admin password. I thnk I'm doing something wrong.any help. Ciao. ___ 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] System Priority
Really doesn't matter. One could have priority=12 and the other = 31.
This could be caused by manually editing the main.cf and creating your
own service groups.
I have seen it in the hagui when sys1 is added first (priority=0), then
sys2 is added (priority=1), then sys1 is removed from the system list
and added back to make sys2 the higher priority. When sys2 is added back
it becomes priority=2. Another example could be having sys1, sys2 and
then removing sys1 and adding another system to the cluster and adding
it to the SG.
In VCS 1.12 and 1.2 etc we did a lot of command line rather than GUI and
you could set up any numbers you wanted for priority.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of i man
Sent: Friday, May 30, 2008 5:45 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] System Priority
I have noticed a few main.cf file where two node clusters are recorded
with different priorities for different service groups. like below
group XX (
SystemList = { sunibm01 = 0, sunibm02 = 1 }
)
group NETWORK (
SystemList = { sunibm01 = 1, sunibm02 = 2 }
Is this normal ?
___
Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] Tweaking monitors
FaultOnMonitorTimeout is obviously set to 4 and you are having more than
4 timeouts. That is 4 minutes of non-monitoring. You could increase FOTM
or the monitor interval or both.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manuel
Braun
Sent: Thursday, April 10, 2008 1:19 PM
To: Andrey Dmitriev; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] Tweaking monitors
Hi Andrey,
are you looking for ToleranceLimit?
Here is an excerpt from the VCS user guide:
About the ToleranceLimit attribute
The ToleranceLimit attribute defines the number of times the Monitor
routine should return an offline status before declaring a resource
offline. This attribute is typically used when a resource is busy and
appears to be offline. Setting the attribute to a non-zero value
instructs VCS to allow multiple failing monitor cycles with the
expectation that the resource will eventually respond. Setting a
non-zero ToleranceLimit also extends the time required to respond to an
actual fault.
Regards
Manuel
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrey
Dmitriev
Sent: Donnerstag, 10. April 2008 18:21
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] Tweaking monitors
All,
The cluster keeps 'spawning' listeners (oracle) under high load, as it
detects it offline (not true)
2008/04/10 09:59:31 VCS INFO V-16-2-13026 (pluto)
Resource(base_listener) - monitor procedure finished successfully after
failing to complete within the expected time for (4) consecutive times.
I'd like it not to declare the resource as faulted until X monitor
failures as well as increase timeout, but I don't remember where to
change those things. Relevant configs attached.
Could someone either point me into the right direction, or tell me a
param off the top of their head to look into?
# hares -display base_listener
#Resource AttributeSystem Value
base_listener Groupglobal pluto_gp
base_listener Type global Netlsnr
base_listener AutoStartglobal 1
base_listener Critical global 1
base_listener Enabled global 1
base_listener LastOnline global pluto
base_listener MonitorOnly global 0
base_listener ResourceOwnerglobal unknown
base_listener TriggerEvent global 0
base_listener ArgListValuesmars oracle
/u81/app/oracle/product/102
/u81/app/oracle/product/102/network/adminbase_listener
./bin/Netlsnr/LsnrTest.pl 0
base_listener ArgListValuespluto oracle
/u81/app/oracle/product/102
/u81/app/oracle/product/102/network/adminbase_listener
./bin/Netlsnr/LsnrTest.pl 0
base_listener ArgListValuessunoracle
/u81/app/oracle/product/102
/u81/app/oracle/product/102/network/adminbase_listener
./bin/Netlsnr/LsnrTest.pl 0
base_listener ConfidenceLevel mars 0
base_listener ConfidenceLevel pluto 100
base_listener ConfidenceLevel sun0
base_listener Flagsmars
base_listener Flagspluto
base_listener Flagssun
base_listener IState mars not waiting
base_listener IState pluto not waiting
base_listener IState sunnot waiting
base_listener Probed mars 1
base_listener Probed pluto 1
base_listener Probed sun1
base_listener Startmars 0
base_listener Startpluto 1
base_listener Startsun0
base_listener Statemars OFFLINE
base_listener Statepluto ONLINE
base_listener StatesunOFFLINE
base_listener AgentDebug global 0
base_listener ComputeStats global 0
base_listener Encoding global
base_listener EnvFile global
base_listener Home global /u81/app/oracle/product/102
base_listener Listener global base_listener
base_listener LsnrPwd global
base_listener MonScriptglobal ./bin/Netlsnr/LsnrTest.pl
base_listener Ownerglobal oracle
base_listener ResourceInfo global State Stale Msg
TS
base_listener TnsAdmin global
/u81/app/oracle/product/102/network/admin
base_listener MonitorTimeStats mars Avg 0 TS
base_listener MonitorTimeStats pluto Avg 0 TS
base_listener MonitorTimeStats sunAvg 0 TS
OracleTypes.cf
type Netlsnr (
static keylist SupportedActions = { VRTS_GetInstanceName,
VRTS_GetRunningServices }
static int OnlineRetryLimit = 2
static int RestartLimit = 2
static str ArgList[] = { Owner, Home, TnsAdmin, Listener,
EnvFile, MonScript, LsnrPwd, AgentDebug, Encoding }
str Owner
str Home
str TnsAdmin
str Listener
str EnvFile
str MonScript =
Re: [Veritas-ha] Restart VCS and GAB
Edit the /etc/llttab on both systems, change the ce4 to ce3, restart VCS, gab, llt. you can use #lltstat -nvv |more to see which port is not connected. note that is not -n w, but -n v v (with no spaces between them). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karthik Sent: Monday, February 18, 2008 4:58 PM To: Tom Stephens Cc: veritas-ha@mailman.eng.auburn.edu Subject: Re: [Veritas-ha] Restart VCS and GAB Hi, Yes'day I changed local-mac-address? to true on 3rd node and rebooted.Initiallly gabconfig -a output was fine showing no jeopardy lines.But after an hour I received VCS warning same as before showing jeopardy status. I'm assuming there might be problem with that specific network port say ce4. what should I do if i want to change this provate NIC to other port ce3? I appreciate your response. Karthik On 2/8/08, Tom Stephens [EMAIL PROTECTED] wrote: You shouldn't need to restart GAB/LLT, as it should automatically heal it's self when the links are re-established. You may want to recheck the cabling again. Tom From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karthik Sent: Friday, February 08, 2008 3:53 PM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] Restart VCS and GAB Hi all, We have 3 node VCS cluster running 4.1.Please see the output of gabconfig below gabconfig -a GAB Port Memberships = Port a gen 255b2e membership 012 Port a gen 255b2e jeopardy ; 2 Port h gen 255b32 membership 012 Port h gen 255b32 jeopardy ; 2 I found that one of the private links on 3rd node was down.It has a cable issue .I fixed it now. how to get rid of the jeopardy line in the output.So I need to restart VCS and GAB.If so how do I do it without disturbing the running cluster service groups. I would appreciate the response on this, Thanks Karthik ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] Is VxVM mirror supported in VCS GCO option?
To mirror volumes you must be dealing with a relatively small distance, such as less than 80K. For these distances, why not use a single cluster called a stretch or campus cluster? In SF 5.0 there is the concept of site awareness so that VM is aware of the two sites and if a volume at the remote site becomes detached, then all volumes at the remote site are detached thereby maintaining consistency of the site. I have not heard of the limitation you mention, I do know that in a Replicated Data Cluster (VVR within a cluster), synchronous replication is required because unlike GCO there is nothing to prevent failover and we don't want the cluster to experience failovers and take over with old data automatically. With mirroring, it certainly would be possible. As in the case of replicating data we do not recommend automatic failover. Automatic failover could result in split brain destroying the data if the link between the two clusters were interrupted making it appear the primary cluster was down. A lot of configurations are possible, a lot will work, but they may not be supported. I am not sure who told you this, but I would ask for an explanation. One possible problem could be the loss of SAN between sites for hours followed by a failover to the remote site with old data with the VCS admin being unaware of the storage problem. I think the primary concern is split brain. With replication, you are working with two distinct data sets. If both sides become active due to a loss of connectivity, the data is not being corrupted, the two sites are just growing further apart. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pavel A Tsvetkov Sent: Friday, December 28, 2007 5:15 AM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] Is VxVM mirror supported in VCS GCO option? Hello all! Just one interesting question about VCS GCO. I was told that VxVM mirror is not supported if using with Global Cluster Option. Only replicated volumes can be used ... Is it true? It seems strange to me... Why not? I think it is quite possible to failover mirrored VxVM volume between clusters... Or not??? Kind regards Pavel Tsvetkov ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] IPMultiNICB deprecated flag migration
Look at the options to IP resource Sent by Good Messaging (www.good.com) -Original Message- From: Evsyukov, Sergey [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 16, 2007 04:42 AM US Mountain Standard Time To: veritas-ha@mailman.eng.auburn.edu Subject:[Veritas-ha] IPMultiNICB deprecated flag migration Hello gents, we need migrate DEPRECATED flag with IP-adress by switch/failover procedure. Is it possible? OS - Solaris 9 VCS - 4.1 Thank you, Sergey ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] setup listener to send email alert
There are definite advantages to having the notifier in the
ClusterService Group. First, notification is a cluster level function.
Second CS group has Special powers like a super group. Because of its
importance in Global Clusters, CSG is the first group online (your
notifications get delivered earlier), it cannot be autodisabled (you may
get messages from both sides of a split brain, if you didn't design
well), it will failover regardless and cannot be frozen. All in all, CSG
is a good home for notifier.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrey
Dmitriev
Sent: Wednesday, June 27, 2007 4:25 PM
To: [EMAIL PROTECTED]; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] setup listener to send email alert
Notifier?
group notify (
SystemList = { host1 = 0, host2 = 1 }
PrintTree = 0
AutoStartList = { host1, host2 }
)
NotifierMngr notifier (
SmtpServer = your.smtp
SmtpRecipients = { [EMAIL PROTECTED] = Error }
)
-a
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 27, 2007 4:12 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] setup listener to send email alert
Hi veritas-ha,
I just joined the mailing list and have a question concerning setting up
vcs to send email alert
when listener is restarted from process dying.
How and where do I set this up to email an account when vcs restarts a
died listener process.
Thnx,
Kevin.
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of any
financial instrument or as an official confirmation of any transaction.
All market prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of
JPMorgan Chase Co., its subsidiaries and affiliates. This transmission
may contain information that is privileged, confidential, legally
privileged, and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED. Although
this transmission and any attachments are believed to be free of any
virus or other defect that might affect any computer system into which
it is received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase Co., its subsidiaries and affiliates, as applicable,
for any loss or damage arising in any way from its use. If you received
this transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard copy
format. Thank you. Please refer to
http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK
legal entities.
___
Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] replacing nodes with newer Veritas VCS Softwareinstalled
Versions of VCS/GAB/LLT must be the same within a cluster. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Weber, Klaus Sent: Monday, April 16, 2007 4:04 AM To: veritas-ha@mailman.eng.auburn.edu Subject: [Veritas-ha] replacing nodes with newer Veritas VCS Softwareinstalled We are in the process of replacing 2 Sunfire V880 with newer V490 systems. the current versions installed are Solaris 8 VCS 3.5 The new 490 are installed with Solaris 9 VCS 4.1 will there be any side effects when 1. creating a 3-way cluster by adding a 490 having VCS 4.1 installed to the exisiting 2-Way cluster having 3.5 installed 2. after creating the 3-Way cluster we are going to remove one of the 880 (VCS3.5) 3. doing the above steps with the next 880 sincerely Klaus ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
Re: [Veritas-ha] Proxy resource in status unknown
One other reason for not Enabled: some resources run a Open entry
point when you enable them to create some structure in memory. If all
attributes are not sec correctly, such as when creating resources from
the command line, the structure would be incorrectly built and then
would not come online. In class we recommend that anytime you change
attributes you should disable the resource, make the change and then
Enable. As soon as you enable, a monitor is run.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cronin,
John S
Sent: Monday, April 16, 2007 12:37 PM
To: Fred Grieco; Jim Senicka; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] Proxy resource in status unknown
Yes:
Enabled defaults to 0, because until you have the attributes for a
resource configured the monitor will almost surely fail because it
doesn't have sufficient information to check the status, and this is
extremely inconvenient while you are trying to configure the resource.
In the period between creating the resource and having it configured
enough for successful monitoring, you really don't want VCS trying to
monitor it.
Critical defaults to 1 because once you have enabled the resource, you
will probably want it to be Critical - it would be easy to forget to
change it to Critical if that was something you were required to do, and
then you might not notice the problem until the first time a resource
faulted and did NOT failover as you probably expected it to do.
--
John Cronin
678-480-6266
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fred
Grieco
Sent: Monday, April 16, 2007 12:22 PM
To: Fred Grieco; Jim Senicka; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] Proxy resource in status unknown
This started when I copied the resource from another service group.
As an aside, is there a reason why resources are defaulted to disabled
and critical when they are created or copied?
--- Fred Grieco [EMAIL PROTECTED] wrote:
Ugh... I didn't see that. That solved the problem.
Thanks,
Fred
--- Jim Senicka [EMAIL PROTECTED] wrote:
The actual NIC is not enabled, so the Proxy cannot probe. (at least
that is my first thought here)
-Original Message-
From: Fred Grieco [mailto:[EMAIL PROTECTED]
Sent: Monday, April 16, 2007 11:29 AM
To: Jim Senicka; veritas-ha@mailman.eng.auburn.edu
Subject: RE: [Veritas-ha] Proxy resource in
status
unknown
Here are the snipets from the main.cf. There are three SGs, one
with the actual NIC resource and two with proxies.
Both
proxies show the
online status unknown state.
group ClusterService (
SystemList = { pa-ocsun-01 = 0,
pa-ocsun-02
=
1 }
AutoStartList = { pa-ocsun-01, pa-ocsun-02
}
OnlineRetryLimit = 3
OnlineRetryInterval = 120
)
IP webip (
Device = ce0
Address = 192.168.49.146
NetMask = 255.255.255.0
)
...
Proxy NICProxycsg (
Critical = 0
TargetResName = nic1
)
group VVR-Remote (
SystemList = { pa-ocsun-01 = 0,
pa-ocsun-02
=
1 }
)
...
IP replip (
Critical = 0
Device = ce0
Address = 192.168.49.68
NetMask = 255.255.255.0
)
NIC nic1 (
Enabled = 0
Device = ce0
NetworkType = ether
NetworkHosts = { 192.168.49.1 }
)
...
group oc451 (
SystemList = { pa-ocsun-01 = 0,
pa-ocsun-02
=
1 }
AutoStartList = { pa-ocsun-01, pa-ocsun-02
}
)
...
IP VIP (
Critical = 0
Device = ce0
Address = 192.168.49.145
NetMask = 255.255.255.0
)
...
Proxy NIC-Proxy (
Critical = 0
TargetResName = nic1
)
...
Fred
--- Jim Senicka [EMAIL PROTECTED]
wrote:
Can you cut/paste main.cf sections?
-Original Message-
From: Fred Grieco [mailto:[EMAIL PROTECTED]
Sent: Monday, April 16, 2007 9:30 AM
To: Jim Senicka;
veritas-ha@mailman.eng.auburn.edu
Subject: RE: [Veritas-ha] Proxy resource in
status unknown
Yes, with the same priorities.
--- Jim Senicka [EMAIL PROTECTED]
wrote:
Are the system lists for both service groups
the
same?
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Fred
Grieco
Sent: Monday, April 16, 2007 9:08 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] Proxy resource in
status
unknown
I've set up a proxy resource that
Re: [Veritas-ha] VCS with Blades
Newer versions of VCS are kinder and better than 1.3. Node number can be duplicate, but cluster IDs need to be unique if they will be out on the same network (remember LLT doesn't get routed, so it isn't going everywhere). With current VCS, if LLT sports a duplicate, it will announce that it sees the duplicate and disable LLT on that port. In addition to changing the cluster IDs, you can also change SAP (default=CAFÉ) as some companies do with multiple operating systems using VCS. Another thing to note is that the range of cluster IDs is not limited to the old 0-255, it is now 0-65000 some odd number. Getting too old to remember large numbers like that. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Dmitriev Sent: Friday, March 02, 2007 1:23 PM To: [EMAIL PROTECTED] Subject: Re: [Veritas-ha] VCS with Blades If you do over public. Make sure your cluster ID is unique, and maybe node IDs too across different clusters on the network/subnet. That bit us on an older version of VERITAS Cluster (1.3) -a _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanley, Jon Sent: Friday, March 02, 2007 10:51 AM To: Kiss László - Károly; [EMAIL PROTECTED] Subject: Re: [Veritas-ha] VCS with Blades I know that in HP blades you can put in mezziane cards that give you additional ports beyond the on-board (they have two slots, so you could put in a dual-channel FC card, I think, and a quad-port Ethernet adapter). I think that you *can* use the public network for LLT, not sure if this is actually supported or not for anything other than a lowpri link. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kiss László - Károly Sent: Friday, March 02, 2007 10:23 AM To: [EMAIL PROTECTED] Subject: [Veritas-ha] VCS with Blades Hi, Does anyone have experience using VCS with IBM Blades? Especially with Blade LS21? We are just planning to use this hardware and the first problem is the lack of resource for heartbeat link. The Blade has only 2 network ports and both are used for the public network so no interface remains for the heartbeat private network. Is there any other choice for the heartbeat link than private network? Thanks. Best Regards, Laszlo _ Don't get soaked. Take a quick peak at the forecast http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail#news with theYahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail#news ___ Veritas-ha maillist - Veritas-ha@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
