[Lustre-discuss] Question on setting up fail-over

Tue Aug 17 12:24:55 PDT 2010

That is good to know, but already started formatting. No issues as it
hasn't been put into production, just playing with it and working
kinks like this out. Though formatting the OSTs was rather quick while
the MDT is taking some time. Is this normal?

192.168.5.105 is the other(standby) mds node.
[root at meta1 ~]# mkfs.lustre --reformat --fsname=lustre --mgs --mdt
--failnode=192.168.5.105 at tcp0 /dev/lustre-mdt-dg/lv1

   Permanent disk data:
Target:     lustre-MDTffff
Index:      unassigned
Lustre FS:  lustre
Mount type: ldiskfs
Flags:      0x75
              (MDT MGS needs_index first_time update )
Persistent mount opts: iopen_nopriv,user_xattr,errors=remount-ro
Parameters: failover.node=192.168.5.105 at tcp
mdt.group_upcall=/usr/sbin/l_getgroups

device size = 2323456MB
2 6 18
formatting backing filesystem ldiskfs on /dev/lustre-mdt-dg/lv1
	target name  lustre-MDTffff
	4k blocks     594804736
	options        -J size=400 -i 4096 -I 512 -q -O
dir_index,extents,uninit_groups,mmp -F
mkfs_cmd = mke2fs -j -b 4096 -L lustre-MDTffff  -J size=400 -i 4096 -I
512 -q -O dir_index,extents,uninit_groups,mmp -F
/dev/lustre-mdt-dg/lv1 594804736

David

On Tue, Aug 17, 2010 at 12:27 PM, Wojciech Turek <wjt27 at cam.ac.uk> wrote:
> Hi David,
>
> You need to umount your OSTs and MDTs and run tunefs.lustre  --writeconf
> /dev/<lustre device> on all Lustre OSTs and MDTs This will force the lustre
> targets to fetch new configuration next time they are mounted. The order of
> mounting is: MGT -> MDT -> OSTs
>
> Best regards,
>
> Wojciech
>
>
>
> On 17 August 2010 18:19, David Noriega <tsk133 at my.utsa.edu> wrote:
>>
>> Oppps some how I changed the target name of all OSTs to lustre-OST0000
>> and trying to mount any other ost fails. I've gone and found the 'More
>> Complicated Configuration' section which details the usage of
>> --mgsnode=nid1,nid2 and so using this I think I'll just reformat.
>>
>> On Tue, Aug 17, 2010 at 11:26 AM, David Noriega <tsk133 at my.utsa.edu>
>> wrote:
>> > Some info:
>> > MDS/MGS 192.168.5.104
>> > Passive failover MDS/MGS 192.168.5.105
>> > OSS1 192.168.5.100
>> > OSS2 192.168.5.101
>> >
>> > I've got some more questions about setting up failover. Besides having
>> > heartbeat setup, what about using tunefs.lustre to set options?
>> >
>> > On the MDS/MGS I set the following options
>> > tunefs.lustre --failnode=192.168.5.105 /dev/lustre-mdt-dg/lv1
>> > Heartbeat works just fine, can mount on the primary node and then
>> > failover to the other and back.
>> >
>> > Now on the OSSs things get a bit more confusing. Reading these two blog
>> > posts:
>> >
>> > http://mergingbusinessandit.blogspot.com/2008/12/implementing-lustre-failover.html
>> > http://jermen.posterous.com/lustre-mds-failover
>> >
>> > From these I tried these options:
>> > tunefs.lustre --erase-params --mgsnode=192.168.5.104 at tcp0
>> > --mgsnode=192.168.5.105 at tcp0 --failover=192.168.5.101 at tcp0
>> > -write-params /dev/lustre-ost1-dg1/lv1
>> >
>> > I ran that for all for OSTs, changing the failover option on the last
>> > two OSTs to point OSS1 while the first two point to OST2.
>> >
>> > My understanding is that you mount the OSTs first, then the MDS, but
>> > the OSTs are failing to mount. Are all these options needed? Or is
>> > simply specifying the primary MDS is enough for it to find out about
>> > the second MDS?
>> >
>> > David
>> >
>> > On Mon, Aug 16, 2010 at 2:14 PM, Kevin Van Maren
>> > <kevin.van.maren at oracle.com> wrote:
>> >> David Noriega wrote:
>> >>>
>> >>> Ok I've gotten heartbeat setup with the two OSSs, but I do have a
>> >>> question that isn't stated in the documentation. Shouldn't the lustre
>> >>> mounts be removed from fstab once they are given to heartbeat since
>> >>> when it comes online, it will mount the resources, correct?
>> >>>
>> >>> David
>> >>>
>> >>
>> >>
>> >> Yes: on the servers, they must be not there or "noauto".  Once you
>> >> start
>> >> running heartbeat,
>> >> you have given control of the resource away, and must not mount/umount
>> >> it
>> >> yourself
>> >> (unless you stop heartbeat on both nodes in the HA pair to get control
>> >> back).
>> >>
>> >> Kevin
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Personally, I liked the university. They gave us money and facilities,
>> > we didn't have to produce anything! You've never been out of college!
>> > You don't know what it's like out there! I've worked in the private
>> > sector. They expect results. -Ray Ghostbusters
>> >
>>
>>
>>
>> --
>> Personally, I liked the university. They gave us money and facilities,
>> we didn't have to produce anything! You've never been out of college!
>> You don't know what it's like out there! I've worked in the private
>> sector. They expect results. -Ray Ghostbusters
>> _______________________________________________
>> Lustre-discuss mailing list
>> Lustre-discuss at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>
>
>
> --
> Wojciech Turek
>
> Senior System Architect
>
> High Performance Computing Service
> University of Cambridge
> Email: wjt27 at cam.ac.uk
> Tel: (+)44 1223 763517
>

-- 
Personally, I liked the university. They gave us money and facilities,
we didn't have to produce anything! You've never been out of college!
You don't know what it's like out there! I've worked in the private
sector. They expect results. -Ray Ghostbusters