rgerhards at hq
Jul 13, 2012, 2:33 AM
Post #3 of 3
(190 views)
Permalink
|
|
Re: RELP failover and reliability questions
[In reply to]
|
|
> -----Original Message-----
> From: rsyslog-bounces [at] lists [mailto:rsyslog-
> bounces [at] lists] On Behalf Of david [at] lang
> Sent: Friday, July 13, 2012 1:34 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] RELP failover and reliability questions
>
> On Wed, 11 Jul 2012, Yatchmenoff, Sam wrote:
>
> > Is it possible to use the $ActionExecOnlyWhenPreviousIsSuspended
> > failover mechanism with the RELP output module? If this is not
> > possible, are there any other alternatives for failing over to
> another
> > server in case of a server failure?
>
> sorry, I can't answer this for sure, but I think it should work
Works with any action - because the action plugin is not involved in that process other than that it needs to provide status information.
>
> > Also, do the RELP modules guarantee that the logs are written to disk
> > at the receiving end? Do I need to have a disk queue at the receiving
> > end to guarantee this?
>
> If you want to _guarantee_ that the logs are written to disk on the
> receiving end you not only need to use the disk queue, but you also
> need
> to have it fsync after each log message.
>
> This absolutly kills performance. A few years ago I did some tests with
> this and on a high-end SSD (Fusion-IO SSD card) the logging speed
> dropped
> to about 2000 messages/sec on ext3 (about 8K messages/sec on ext2 and
> 4K
> messages/sec on XFS). This is significantly worse than traditional
> syslog,
> because rsyslog needs to do multiple disk I/Os for each message
> (putting
> it in the queue, pulling it out of the queue to be worked on, writing
> the
> message to the log file, updating the queue to show that it was
> processed), and the disk queue itself is very inefficient (it closes
> and
> re-opens the queue files for every access)
I'd phrase that a bit differently: the queue files are kept open. HOWEVER, if you set the queue to sync after each write, the queue status file must also be persisted. So there is the write to the queue file, the fsync for the queue file PLUS an open, write and close for the status file. No way around this if you want to keep everything save (well, we could keep the status file open and truncate it, that's right...).
>
> There are some logs where this level of paranoia is justified, but not
> in
> most cases.
>
> In most cases you are better off putting the receiving box on a UPS and
> sending the log to multiple boxes and relying on the boxes not going
> down
> at the same time.
>
Full ack.
Rainer
> David Lang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
|
