We are contemplating the use of external journals on our OST and MDS nodes in order to gain more consistent throughput to the back-end RAIDs. I understand there might be fail-over implications? --Lee
Hi Lee: At present there are indeed some failover (usually for failback) implications. When failing back one of more targets from one server to another we cannot rip out the server and to get a clean IO fence. Instead we make the MDT/OST device that is being failed back a "dumb" read-only (it just drops all writes, no errors). At present we do not have the capability to turn an external journal device read-only in the same way. However, it''s a simple enhancement and I encourage you to simply file a defect with us for this. Almost certainly there is a bug assigned for this already. - Peter - -----Original Message----- From: lustre-discuss-bounces@clusterfs.com [mailto:lustre-discuss-bounces@clusterfs.com] On Behalf Of Lee Ward Sent: Thursday, July 06, 2006 10:52 AM To: Lustre Discuss Subject: [Lustre-discuss] External journals We are contemplating the use of external journals on our OST and MDS nodes in order to gain more consistent throughput to the back-end RAIDs. I understand there might be fail-over implications? --Lee _______________________________________________ Lustre-discuss mailing list Lustre-discuss@clusterfs.com https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
To failback a service to its original node. Couldn''t you just stop it wheres its running, making sure all currently running transactions are flushed to disk, and then restart it on its original node? This sounds like it would work provided both nodes have acccess to the journal and the storage. tim --- "Peter J. Braam" <braam@clusterfs.com> wrote:> Hi Lee: > > At present there are indeed some failover (usually > for failback) > implications. > > When failing back one of more targets from one > server to another we > cannot rip out the server and to get a clean IO > fence. Instead we make > the MDT/OST device that is being failed back a > "dumb" read-only (it just > drops all writes, no errors). > > At present we do not have the capability to turn an > external journal > device read-only in the same way. However, it''s a > simple enhancement > and I encourage you to simply file a defect with us > for this. Almost > certainly there is a bug assigned for this already. > > - Peter - > > -----Original Message----- > From: lustre-discuss-bounces@clusterfs.com > [mailto:lustre-discuss-bounces@clusterfs.com] On > Behalf Of Lee Ward > Sent: Thursday, July 06, 2006 10:52 AM > To: Lustre Discuss > Subject: [Lustre-discuss] External journals > > We are contemplating the use of external journals on > our OST and MDS > nodes in order to gain more consistent throughput to > the back-end RAIDs. > I understand there might be fail-over implications? > > --Lee > > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com >https://mail.clusterfs.com/mailman/listinfo/lustre-discuss> > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com >https://mail.clusterfs.com/mailman/listinfo/lustre-discuss> >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
It''s not that simple - the issue is that (1) the clients must not get errors while the server target is being shutdown; if the clients were to get errors they wouldn''t have the pleasant "failover experience" (2) the server disks must not see any partial transactions while the server is being shut down. For the first we fence the network traffic for the target, but that doesn''t stop the running server processes (which can do all kinds of things, like talk with other servers, make callbacks and so on). To make sure nothing reaches the disk we shut-down the disk. We have a slightly different code path in mind to handle this in the future, which can handle more errors and doesn''t rely on hard fencing techniques. But what we have is, we believe, a solution that protects the failover process from not completing correctly. - peter - -----Original Message----- From: Tim Cullen [mailto:timcullen2001@yahoo.com] Sent: Thursday, July 06, 2006 11:11 AM To: Peter J. Braam Cc: lustre-discuss@clusterfs.com Subject: RE: [Lustre-discuss] External journals To failback a service to its original node. Couldn''t you just stop it wheres its running, making sure all currently running transactions are flushed to disk, and then restart it on its original node? This sounds like it would work provided both nodes have acccess to the journal and the storage. tim --- "Peter J. Braam" <braam@clusterfs.com> wrote:> Hi Lee: > > At present there are indeed some failover (usually > for failback) > implications. > > When failing back one of more targets from one > server to another we > cannot rip out the server and to get a clean IO > fence. Instead we make > the MDT/OST device that is being failed back a > "dumb" read-only (it just > drops all writes, no errors). > > At present we do not have the capability to turn an > external journal > device read-only in the same way. However, it''s a > simple enhancement > and I encourage you to simply file a defect with us > for this. Almost > certainly there is a bug assigned for this already. > > - Peter - > > -----Original Message----- > From: lustre-discuss-bounces@clusterfs.com > [mailto:lustre-discuss-bounces@clusterfs.com] On > Behalf Of Lee Ward > Sent: Thursday, July 06, 2006 10:52 AM > To: Lustre Discuss > Subject: [Lustre-discuss] External journals > > We are contemplating the use of external journals on > our OST and MDS > nodes in order to gain more consistent throughput to > the back-end RAIDs. > I understand there might be fail-over implications? > > --Lee > > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com >https://mail.clusterfs.com/mailman/listinfo/lustre-discuss> > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com >https://mail.clusterfs.com/mailman/listinfo/lustre-discuss> >__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com