Re: Reallocation of volumes
Steve Dobbelstein <[email protected]> Thu, 24 Apr 2008 16:42:46 -0500
| Newsgroups | gmane.linux.evms.devel |
|---|---|
| Message-ID | <OF1D226D83.DE739024-ON85257435.0075C6E3-86257435.0077486F@us.ibm.com> |
--===============1800389029== Content-type: multipart/alternative; Boundary="0__=0ABBFEA6DFE640738f9e8a93df938690918c0ABBFEA6DFE64073" Content-Disposition: inline --0__=0ABBFEA6DFE640738f9e8a93df938690918c0ABBFEA6DFE64073 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable "Francois Pernet" <[email protected]> wrote on 04/23/2008 01:30:3= 5 AM: > "Francois Pernet" <[email protected]> > Sent by: [email protected] > > 04/23/2008 01:30 AM > > To > > <[email protected]> > > cc > > Subject > > [Evms-devel] Reallocation of volumes > > Hi there, > > Veritas apparently uses a technique in order to perform smooth backup= . > AFAIK, the goal is to create on a Volume Manager (LVM has been > tested successfully), two mirrored volumes (soft RAID1). Of course, > everything is on a SAN. > Everything runs like that during normal operation. When backup > starts, their agent, based on shell script, breaks the mirror, > desallocates somehow one of mirrored voume. When mirror is broken, > one of the volume is picked up by from another server which then can > be backup without problem (no open files, can have large backup > window's size, etc..). > When backup is over, the volume is removed from the local LVM and > reinserted in the original server. > Mirror is then resynchronised... > > My question is : is it possible, with evms (we have SLES9 with evms > installed and XFS file system on SAN) to to dynamically remove a volu= me from > a storage container then add it into another storage container on > another server , and the other way around ? > Does somebody tried this Veritas feature with evms ? > > many thanks for your help > > Francois Hi, Francois. EVMS supports the concepts of "disk groups" for shared storage in a cluster. Disks that are on shared storage can be put into groups. The= groups can then be designated as shared among all nodes in the cluster = or private to only one node in the cluster. EVMS running on one node wi= ll not display disks that are privately owned by another node. EVMS suppo= rts changing of the ownership and the change from/to private and shared. I= t coordinates the changes with the other nodes in the cluster, e.g., remo= ves it from the previous owning node and makes it available on the new owni= ng node. It's pretty nifty functionality, IMHO, but I can think of two reasons w= hy it may not work for you. One is that it only works in conjunction with= clustering software. (For safety, it checks to make sure the node is a= member of the cluster. If not, then it can't safely coordinate disk configuration changes between the nodes.) If you are not running your machines in a cluster (EVMS supports Linux HA and IBM's RSCT) then it w= on't work for you. (There are some ways to circumvent the safety checks, bu= t you do it at the risk of your own peril.) Second is that the disk group feature must be the first thing put on a disk. After that the disk can be partitioned, put into a RAID, etc. I= f you already have data on the disk(s) Then the only way to install the = disk group function would be to backup your data, reconfigure your disk to b= e in a disk group, do whatever you did before to make volumes from the disk (partition it, assign it to a RAID, etc.), and then restore your data t= o the volume. Steve D.= --0__=0ABBFEA6DFE640738f9e8a93df938690918c0ABBFEA6DFE64073 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p><tt>"Francois Pernet" <[email protected]></tt>= <tt> w</tt><tt>rote on 04/23/2008 01:30:35 AM:<br> <br> > "Francois Pernet" <[email protected]> </tt><= br> <tt>> Sent by: [email protected]<br> > </tt><br> <tt>> 04/23/2008 01:30 AM</tt><br> <tt>> <br> > To</tt><br> <tt>> <br> > <[email protected]></tt><br> <tt>> <br> > cc</tt><br> <tt>> <br> > Subject</tt><br> <tt>> <br> > [Evms-devel] Reallocation of volumes</tt><br> <tt>> <br> > Hi there,<br> > <br> > Veritas apparently uses a technique in order to perform smooth bac= kup.<br> > AFAIK, the goal is to create on a Volume Manager (LVM has been <br= > > tested successfully), two mirrored volumes (soft RAID1). Of course= , <br> > everything is on a SAN.<br> > Everything runs like that during normal operation. When backup <br= > > starts, their agent, based on shell script, breaks the mirror, <br= > > desallocates somehow one of mirrored voume. When mirror is broken,= <br> > one of the volume is picked up by from another server which then c= an<br> > be backup without problem (no open files, can have large backup <b= r> > window's size, etc..).<br> > When backup is over, the volume is removed from the local LVM and = <br> > reinserted in the original server.<br> > Mirror is then resynchronised... <br> > <br> > My question is : is it possible, with evms (we have SLES9 with evm= s <br> > installed and XFS file system on SAN) to to dynamically remove a v= olume from<br> > a storage container then add it into another storage container on = <br> > another server , and the other way around ?<br> > Does somebody tried this Veritas feature with evms ?<br> > <br> > many thanks for your help<br> > <br> > Francois</tt><br> <br> <tt>Hi, Francois.<br> </tt><br> <tt>EVMS supports the concepts of "disk groups" for shared st= orage in a cluster. Disks that are on shared storage can be put i= nto groups. The groups can then be designated as shared among all= nodes in the cluster or private to only one node in the cluster.  = ; EVMS running on one node will not display disks that are privat= ely owned by another node. EVMS supports changing of the ownershi= p and the change from/to private and shared. It coordinates the c= hanges with the other nodes in the cluster, e.g., removes it from the p= revious owning node and makes it available on the new owning node.</tt>= <br> <br> <tt>It's pretty nifty functionality, IMHO, but I can think of two reaso= ns why it may not work for you. One is that it only works in conj= unction with clustering software. (For safety, it checks to make = sure the node is a member of the cluster. If not, then it can't s= afely coordinate disk configuration changes between the nodes.) I= f you are not running your machines in a cluster (EVMS supports Linux H= A and IBM's RSCT) then it won't work for you. (There are some way= s to circumvent the safety checks, but you do it at the risk of your ow= n peril.)</tt><br> <br> <tt>Second is that the disk group feature must be the first thing put o= n a disk. After that the disk can be partitioned, put into a RAID= , etc. If you already have data on the disk(s) Then the onl= y way to install the disk group function would be to backup your data, = reconfigure your disk to be in a disk group, do whatever you did before= to make volumes from the disk (partition it, assign it to a RAID, etc.= ), and then restore your data to the volume.</tt><br> <br> <tt>Steve D.</tt></body></html>= --0__=0ABBFEA6DFE640738f9e8a93df938690918c0ABBFEA6DFE64073-- --===============1800389029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone --===============1800389029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Evms-devel mailing list [email protected] To subscribe/unsubscribe, please visit: https://lists.sourceforge.net/lists/listinfo/evms-devel --===============1800389029==--