We see poor I/O throughput results for our shared storage which is currently on OCFS2 file system(OS - Oracle Linux). We tried creating logical volumes similar to what it's suggested on Optimizing SAS on RHEL 6 and 7 paper and failed. Unfortunately, OCFS2 does not support logical volumes and results in corruption.
Also found in the Shared File Systems paper as a customer is using Oracle ACFS file system without any issues. Is anyone in the community using ACFS file system?
Neither OCFS2 nor ACFS has been tested at the SAS Performance Lab. OCFS has been tested but the results are not satisfactory.
Is there any other recommended file system that can be used on Oracle Linux for shared storage rather than rebuilding our entire environment?
Hello @Akshay_93 ,
Indeed, OCFS is not the kind of shared file system you would look at when looking for performance. Therefore not recommended when you focus on that performance. I will share a few explanations below, if they can help you, or for other who read. If you are not interested or they are TLTR (Too Long To Read), I would simply advise you to check out Veritas, IBM GPFS (Spectrum Scale) or Lustre, as they are the most popular ones for on-premises. Check compatibility, performance and versions.
And here is my little speech and references, I hope they can help some folks:
SAS R&D passes A LOT of testing and can share many-many recommendations about file systems. But SAS is not the expert on file systems. SAS is a SME (Subject Matter Expert), in the SAS software, of course. Each party or software vendor is an expert on their own terrain, and SAS is not OS or cloud or file system expert. A good architect or team of architects can help you by putting all of this expertise together and bring some light.
You may approach this challenge on several ways. Some I can think of:
- you act as architect and start reading and studying more about SAS, Oracle and the file systems, what can be the best solution for your platform. You still might need to contact your vendors or prospects, but with your homework, you will minimize time and costs.
- you bring an architect or a team of architects together to work on this and they will communicate with vendors/prospects. Time and costs might be a fair middle-ground.
- you can ask right away every vendor and pur them together, to find a solution. They will assign their pre-sales and architects to work with you, probably being the most expensive solution. Time-wise, it depends.
- as another middle-ground, you might want to contact an experienced partner. If your system is Oracle, you might want to consult with Oracle or an Oracle partner. And SAS. An example: https://blogs.oracle.com/cloud-infrastructure/sas-grid-now-validated-on-oracle-cloud-infrastructure
All in all, leaving theory aside, some few concepts and references:
- Look always to the basic/foundation concepts and requirements for each component. Abstraction and a clear mind helps.
- SAS performance counts in terms of Throughput I/O, meaning sequential, in opposition of IOPS (random). On every paper or SAS documentation you will realize it is a constant.
- You will look not only from your file system point of view, but also from end-to-end (SAS Compute-network-filesystem) the required throughput, and there is going a bottleneck for certain, you can choose where it will be (file system, network, network card, number of cores, etc). Having an on-premises platform will make this harder for you (as you have more choices) but you can optmize a lot, being more efficient.
- the way to make available disks to the file systems (logical volumes) is always the same: fully stripped and in sets of 4 or 8 physical volumes.
- Read through the basic concepts shared by SAS, across every single year since I have memory: https://communities.sas.com/t5/SAS-Communities-Library/Contemplating-shared-file-systems-for-SAS/ta-...
- Read through the technical requirements, compatibility and performance of the file systems in detail, then get an abstract summary out of them. Perhaps you can start from the ones SAS proposes, and get the updated version every time. The ones @MargaretC publishes are the best resource. You can also look outside the box of course, just beware it might not be fully supported - but if you make it work, you can make a great contribution to the SAS communities.
- The paper for RHEL you mentioned, that is it, it is for RHEL, not Oracle. There are similarities, but also too many variables involved to ensure something that works on RHEL will work on Oracle as well. Excellent example: driver code compilation! Always look at the compatibility and version of the drivers and the system settings that are required.
- ACFS: contact your SAS representative to see if you can get more information from the right channels
- The paper also recommends Veritas. Have you got a chance to give it a look?
- Did you give a look to Lustre? I am personally having great experiences with it. Vendor is now DDN. https://docs.oracle.com/en/solutions/deploy-lustre-fs/index.html#GUID-34A915EF-9A45-4848-93F1-B9B736...
- IBM Spectrum Scale GPFS is a great one for on-premises and with some good notes over Oracle too: https://www.ibm.com/support/knowledgecenter/SSFKCN_4.1.0/com.ibm.cluster.gpfs.v4r1.gpfs300.doc/bl1in...
For now I just wanted to provide you some general pointers and just a few specific references. Long story short, it is of most importance to do our homework before any implementation, to minimize risks and costs. This homework might involve bringing people, strong people, together and effort coordination. And the basic concepts is of key importance, to be able to put the pieces together.
Thanks @JuanS_OCS for the detailed write up. This information helps.
We've tested I/O throughput for ACFS which is on physical servers for a different application. The results were encouraging and planning to test it on our virtual servers this week. Will post the results in the same discussion once done.
I haven't got a chance to look at Veritas.
Lustre or GPFS is something we would tend to consider if* we don't see the expected results with ACFS (hoping for positive results, though).
Again, thanks a lot.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.