[prev in list] [next in list] [prev in thread] [next in thread]
List: veritas-ha
Subject: Re: [Veritas-ha] VVR 3.2 question
From: "Eric Feng Jie" <jfeng () privateexpress ! com ! sg>
Date: 2001-10-26 8:14:48
[Download RAW message or body]
Hi, Brooks,
I'm puzzled again after I did a autosyn test. My conclusion is cksum does not report \
the same even through primary and secondary are in syn, after automatic \
synchronization. When you talk about same bit-pattern, you don't really mean \
bit-by-bit-identical, as required by force synchronization (-f startrep)? Here's my \
test result
7. synchronizing the secondary (automatic synchronization)
Primary:
# vradmin -a startrep replrvg sgldsd01
Messages from Primary :
vxvm:vxrlink: WARNING: Attaching rlink to non-empty rvg. Autosync will be performed.
vxvm:vxrlink: INFO: Secondary data volumes detected with rvg replrvg as parent:
vxvm:vxrlink: INFO: replvol: len=4194304 primary_datavol=replvol
vxvm:vxrlink: INFO: Autosync operation has started
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is in AUTOSYNC. 2072576 Kbytes remaining.
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is in AUTOSYNC. 2053408 Kbytes remaining.
#
...
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is up to date
NOTE: synchronization time is proportional to size of volume (2g = 1/2hr)
8. verifying secondary is in syn
Primary:
# vradmin stoprep replrvg sgldsd01
vradmin: WARNING: Secondary data volumes will become out-of-date.
vradmin: Continue with stoprep (y/n)? y
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is not currently attached (STALE).
#
# cksum /dev/vx/rdsk/rootdg/replvol
3089107577 2147483648 /dev/vx/rdsk/rootdg/replvol
#
It took about 5 minutes to finish.
Secondary:
# vxrvg start replrvg
# cksum /dev/vx/rdsk/rootdg/replvol
729953647 2147483648 /dev/vx/rdsk/rootdg/replvol
#
# vxrvg stop replrvg
#
Resuming replication, this is a bit risky because I use -f startrep due to the fact \
that 'vxrlink status' had reported two volumes are in syn (rlink status up-to-date). \
Primary: # vradmin -f startrep replrvg sgldsd01
Messages from Primary :
vxvm:vxrlink: WARNING: Attaching rlink to non-empty rvg. No checkpoint parameter \
supplied. vxvm:vxrlink: INFO: Secondary data volumes detected with rvg replrvg as \
parent: vxvm:vxrlink: INFO: replvol: len=4194304 primary_datavol=replvol
# umount /replvol
# vradmin migrate replrvg sgldsd01
vradmin: WARNING: Make sure applications using primary data volumes are stopped.
vradmin: Continue with migrate (y/n)? y
#
Secondary:
# mount /replvol
# ls /replvol
lost+found sgldmd01_config.txt smc898
ps_data sh3530
#
Succeed! NOTE: checksum is no longer valid when autosyn? If it is not, what should I \
do to verify primary and secondary are in syn?
Thanks
Eric
----- Original Message -----
From: Brooks Graham
To: 'Eric Feng Jie' ; Gene Henriksen ; veritas-ha@mailman.eng.auburn.edu ; Brooks \
Graham Sent: Friday, October 26, 2001 2:46 AM
Subject: RE: [Veritas-ha] VVR 3.2 question
Okay, after re-reading your initial post more carefully, I see that you've missed a \
very, very important step: Initialization.
Bear with me as this might end up being quite wordy.
The basic philosophy behind VVR is to take volume images that are being used for \
production I/O (the primary) and replicate those images in such a way as to have \
identical volume images maintained at a remote location (the secondary). Now \
remember that in VERITAS Volume Manager, the volume images that are managed by VxVM \
simply contain a pattern of bytes that have some meaning to a higher-level \
application such as a filesystem (VxFS, for example). VxVM has no knowledge of what \
those byte patters represent - it's up to the higher-level application to do that. \
VxVM's role is to manage the layout/configuration of those virtual devices we call \
volumes. The filesystem's role is to place structures down on those volumes and \
implement a common way to access data (files). One way I keep this straight is to \
remember that a volume is never full or empty, it's just a bit-pattern. Filesystems \
get full or can be empty.
Now, with VVR, when we set up a VVR configuration, we start out with a set of \
primary volumes and we make an identical set of volumes on the secondary (their names \
and sizes must *exactly* match). Before we can begin the process of real-time \
replication, we must make the secondary volume images match the primary. When I say \
that, I really mean that we must make the bit-patterns of the secondary volumes match \
the bit patterns of the primary volumes. We call this process "initialization" or \
"initial synchronization." We give you many choices on how to accomplish this \
including a feature we call "Autosync." This will take live, primary volumes and \
move their bit-patterns over to their corresponding secondary volumes over the IP \
network. This works well for either/or small data sets or large pipes (100BT, for \
example).
Looking at your procedure, it appears that you executed a "force attach" of the \
secondary without initializing (vradmin -f att ...) While this appeared to work, it \
does not make the bit-patterns match, it simply starts moving any subsequent updates \
over to the secondary. This left you with secondary volumes that were not usable. \
Note that the "-f" option of *any* VxVM command can be very dangerous. We try and \
tell you when a requested operation is not possible, but that warning can be \
overridden in most cases with "-f". The results are then unpredictable at best. In \
terms of VVR, the "force attach" command really means that you're telling VxVM/VVR \
that *you* know that the bit-patterns of all the volumes in the rvg match *exactly* \
even if VVR does not. There are times when this is appropriate, just not usually for \
initialization purposes.
[I couldn't tell if you did a mkfs on the secondary volumes or not, but you don't \
need to. When you correctly initialize secondary volumes, the bit-patters which \
represent the filesystem structures are moved along with everything else.]
To do an Autosync, if you don't already have them, attach DCM logs to each data \
volume in the rvg (not the SRL) by doing something like "vxassist -g <dgname> addlog \
<volume_name> logtype=dcm". Then execute "vradmin -a startrep ..."
Hope that helps clear up any confusion.
Please let me know if you have any further questions or if I can help in any other \
way.
-bdg
[Brooks Graham]
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>Hi, Brooks,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I'm puzzled again after I did a autosyn test. My
conclusion is cksum does not report the same even through primary and secondary
are in syn, after automatic synchronization. When you talk about same
bit-pattern, you don't really mean bit-by-bit-identical, as required by
force synchronization (-f startrep)? Here's my test result</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>7. synchronizing the secondary (automatic
synchronization)<BR>Primary:<BR># vradmin -a startrep replrvg
sgldsd01<BR>Messages from Primary :<BR>vxvm:vxrlink: WARNING: Attaching rlink to
non-empty rvg. Autosync will be </FONT><FONT face=Arial
size=2>performed.<BR>vxvm:vxrlink: INFO: Secondary data volumes detected with
rvg replrvg as </FONT><FONT face=Arial size=2>parent:<BR>vxvm:vxrlink: INFO:
replvol: len=4194304
primary_datavol=replvol<BR>vxvm:vxrlink: INFO: Autosync operation has
started<BR># vxrlink status 69_to_122<BR>vxvm:vxrlink: INFO: Rlink 69_to_122 is
in AUTOSYNC. 2072576 Kbytes </FONT><FONT face=Arial size=2>remaining.<BR>#
vxrlink status 69_to_122<BR>vxvm:vxrlink: INFO: Rlink 69_to_122 is in AUTOSYNC.
2053408 Kbytes </FONT><FONT face=Arial size=2>remaining.<BR>#<BR>...<BR>#
vxrlink status 69_to_122<BR>vxvm:vxrlink: INFO: Rlink 69_to_122 is up to
date</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>NOTE: synchronization time is proportional to size
of volume (2g = 1/2hr)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>8. verifying secondary is in syn<BR>Primary:<BR>#
vradmin stoprep replrvg sgldsd01</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>vradmin: WARNING: Secondary data volumes will
become out-of-date.<BR>vradmin: Continue with stoprep (y/n)? y<BR># vxrlink
status 69_to_122<BR>vxvm:vxrlink: INFO: Rlink 69_to_122 is not currently
attached (STALE).<BR>#<BR># cksum
/dev/vx/rdsk/rootdg/replvol<BR>3089107577
2147483648 /dev/vx/rdsk/rootdg/replvol<BR>#<BR>It
took about 5 minutes to finish.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Secondary:<BR># vxrvg start replrvg<BR># cksum
/dev/vx/rdsk/rootdg/replvol<BR>729953647
2147483648 /dev/vx/rdsk/rootdg/replvol<BR>#<BR>#
vxrvg stop replrvg<BR>#</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Resuming replication, this is a bit risky because I
use -f startrep due to the fact that 'vxrlink status' had reported two volumes
are in syn (rlink status up-to-date).<BR>Primary:<BR># vradmin -f startrep
replrvg sgldsd01<BR>Messages from Primary :<BR>vxvm:vxrlink: WARNING: Attaching
rlink to non-empty rvg. No checkpoint parameter supplied.<BR>vxvm:vxrlink: INFO:
Secondary data volumes detected with rvg replrvg as parent:<BR>vxvm:vxrlink:
INFO: replvol: len=4194304
primary_datavol=replvol<BR># umount /replvol<BR># vradmin migrate replrvg
sgldsd01</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>vradmin: WARNING: Make sure applications using
primary data volumes are stopped.<BR>vradmin: Continue with migrate (y/n)?
y<BR>#</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Secondary:<BR># mount /replvol<BR># ls
/replvol<BR>lost+found
sgldmd01_config.txt
smc898<BR>ps_data \
sh3530<BR>#</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Succeed! NOTE: checksum is no longer valid when
autosyn? If it is not, what should I do to verify primary and secondary are in
syn?<BR></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Thanks</FONT></DIV>
<DIV><FONT face=Arial size=2>Eric</FONT></DIV>
<DIV> </DIV>
<DIV></FONT>----- Original Message ----- </DIV></DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; \
PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:Brooks@veritas.com" title=Brooks@veritas.com>Brooks Graham</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
href="mailto:jfeng@privateexpress.com.sg"
title=jfeng@privateexpress.com.sg>'Eric Feng Jie'</A> ; <A
href="mailto:gene.henriksen@veritas.com" title=gene.henriksen@veritas.com>Gene
Henriksen</A> ; <A href="mailto:veritas-ha@mailman.eng.auburn.edu"
title=veritas-ha@mailman.eng.auburn.edu>veritas-ha@mailman.eng.auburn.edu</A>
; <A href="mailto:Brooks@veritas.com" title=Brooks@veritas.com>Brooks
Graham</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, October 26, 2001 2:46
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [Veritas-ha] VVR 3.2
question</DIV>
<DIV><BR></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2>Okay, after re-reading your initial post more carefully, I see that
you've missed a very, very important step: Initialization.</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial size=2>Bear
with me as this might end up being quite wordy.</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial size=2>The
basic philosophy behind VVR is to take volume images that are being used for
production I/O (the primary) and replicate those images in such a way as to
have identical volume images maintained at a remote location (the
secondary). Now remember that in VERITAS Volume Manager, the volume
images that are managed by VxVM simply contain a pattern of bytes that have
some meaning to a higher-level application such as a filesystem (VxFS, for
example). VxVM has no knowledge of what those byte patters represent -
it's up to the higher-level application to do that. VxVM's role is to
manage the layout/configuration of those virtual devices we call
volumes. The filesystem's role is to place structures down on those
volumes and implement a common way to access data (files). One way I
keep this straight is to remember that a volume is never full or empty, it's
just a bit-pattern. Filesystems get full or can be empty.
</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial size=2>Now,
with VVR, when we set up a VVR configuration, we start out with a set of
primary volumes and we make an identical set of volumes on the secondary
(their names and sizes must *exactly* match). Before we can begin the
process of real-time replication, we must make the secondary volume images
match the primary. When I say that, I really mean that we must make the
bit-patterns of the secondary volumes match the bit patterns of the primary
volumes. We call this process "initialization" or "initial
synchronization." We give you many choices on how to accomplish this
including a feature we call "Autosync." This will take live, primary
volumes and move their bit-patterns over to their corresponding secondary
volumes over the IP network. This works well for either/or small data
sets or large pipes (100BT, for example).</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2>Looking at your procedure, it appears that you executed a "force
attach" of the secondary without initializing (vradmin -f att ...) While
this appeared to work, it does not make the bit-patterns match, it simply
starts moving any subsequent updates over to the secondary. This left
you with secondary volumes that were not usable. Note that the "-f"
option of *any* VxVM command can be very dangerous. We try and tell you
when a requested operation is not possible, but that warning can be overridden
in most cases with "-f". The results are then unpredictable at
best. In terms of VVR, the "force attach" command really means that
you're telling VxVM/VVR that *you* know that the bit-patterns of all the
volumes in the rvg match *exactly* even if VVR does not. There are times
when this is appropriate, just not usually for initialization
purposes.</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial size=2>[I
couldn't tell if you did a mkfs on the secondary volumes or not, but you don't
need to. When you correctly initialize secondary volumes, the
bit-patters which represent the filesystem structures are moved along with
everything else.]</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial size=2>To
do an Autosync, if you don't already have them, attach DCM logs to each data
volume in the rvg (not the SRL) by doing something like "vxassist -g
<dgname> addlog <volume_name> logtype=dcm". Then execute
"vradmin -a startrep ..."</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial size=2>Hope
that helps clear up any confusion.</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2>Please let me know if you have any further questions or if I can help
in any other way.</FONT></SPAN></DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=515592118-25102001><FONT color=#0000ff face=Arial
size=2>-bdg</FONT></SPAN></DIV><SPAN class=515592118-25102001></SPAN><FONT
face=Tahoma>
<DIV><FONT color=#0000ff face=Arial size=2></FONT><BR><FONT size=2><SPAN
class=515592118-25102001><FONT color=#0000ff face=Arial>[Brooks
Graham] </FONT></SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=515592118-25102001></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN class=515592118-25102001></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN
class=515592118-25102001></SPAN></FONT> </DIV></FONT>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; \
PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>
<DIV> </DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></FONT></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic