Skip to Content
0

SAP HANA - SUSE Linux - Direct IO?

May 02 at 07:29 PM

74

avatar image
Former Member

Hi,

We're using storage replication to a DR site for our SUSE Linux servers. The data/log filesystems are running xfs. We have experienced data loss at the DR site when attempting to recover the FS's as the xfs log cleanup removes the open data/log files (things in lost & found but, it's like putting Humpty Dumpty together again).

Should we be using Direct IO for these FS's to avoid data in cache that hasn't made it to disk for replication causing the FS issues we're seeing at the DR site? Or, is there something else we need to employ to obtain recoverable data?

10 |10000 characters needed characters left characters exceeded
Former Member

We use xfs as the filesystem type on SAN LUNs at one site and the array replicates the data to SAN LUNs at another site. The problem is, the xfs filesystem at the DR site appears as crashed (makes sense since the prod site is up and running during a DR). We must use the log recovery of the xfs filesystem to clean it up and allow us to mount it. This removes the open files - our data and log files - during xfs log recovery process.

0
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Lars Breddemann
May 03 at 01:16 AM
1

SAP HANA uses AsyncIO and DirectIO when opening its files. It's not something you have to specifically configure.

Maybe the corruptions you encounter are due to the numerous XFS filesystem bugs (see the corresponding SAP notes for that).

Show 2 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Lars - any chance you have links to the SAP bugs with xfs? I would really like to understand how we can make recovery at the DR site reliable. If we need to move away from xfs, I'm fine with that. I just need documentation supporting whatever solution is recommended to ensure we are able to recover from a crashed filesystem without data loss. After all, the point of storage-based mirroring is to make it simple for the host/application.


If we're unable to rely on storage-based replication as a reliably recoverable solution, then we'll go back and revisit the other options using HANA-based replication to the DR site.

0

Alright - two things:

  • the bugs/problems I referred to are bugs in the XFS file system, not in SAP HANA. That means, to fix them, a OS patch will be required.
  • I don't know whether or not your problem is related to these bugs. There's just not enough information in this question to make that decision.
    In my experience, analyzing the cause of filesystem errors can become very tedious (going to the point of literally looking into file contents to look for "suspicious" pattern) which is why I always would recommend opening a support incident for the analysis.
  • So, instead of listing some SAP notes related to XFS and HANA, I'll leave this SAP notes search with you:
    https://launchpad.support.sap.com/#/solutions/notesv2/?q=hana%252520xfs&sortBy=score&sortOrder=desc

This should provide you with the SAP notes related to the topic. Hopefully, you are able to match them against the details of your filesystem errors.

0
avatar image
Former Member May 02 at 09:57 PM
0

Tom,

Why not put data/log filesystems on a LUN created by your SAN? In this approach, you can the SAN technology to replicate data (block level) between sites and do not use XFS for this tasks.

Share
10 |10000 characters needed characters left characters exceeded