Just wanted to pass along a known issue with GFS2 on RHEL 9.  It is a data corruption issue.    If you are looking to move to RHEL 9, and you plan to use GFS2as your shared file system, please wait until the issue has been resolved by Red Hat.   ... View more

On April 5 th , Microsoft announced the general availability of their new memory optimized Ebds_v5 Azure Virtual Machines.  Generally available: Azure Virtual Machines increase storage throughput by up to 300% | Azure updates | Microsoft Azure   Details of this new instance can be found here.  Ebdsv5 and Ebsv5 series - Azure Virtual Machines | Microsoft Docs   SAS has tested this new instance and can report that this new instance has increased the IO throughput needed for SAS applications to process large volumes of data using remotely attached Premium storage.  MS Azure has increased the maximum IO throughput to external storage in the Ebds_v5 instances significantly.  By increasing the max IO throughput value there is no longer a need to constrain cores in the instance, like was needed with Eds_v3 and Eds_v4 instances,  to meet the IO throughput needs of SAS applications.    Please work with your local Microsoft team to determine where you can access these new instance types.  And enjoy running SAS on them. ... View more

SAS recently tested SAS 9.4 on MS Azure instances using InfoScale by Veritas. The results of the testing were very favorable.   Test 1: 40 Physical Cores The test infrastructure consisted of the 11 MS Azure instances defined like this:  Five E64-16ds_v4 instances for the SAS clients Six D64s_v3 instances for the IS storage – each with four P60 premium drives. InfoScale 8.0 on RHEL 8.4 was used for the testing.   Architectural Diagram For the test, the follow tunings were applied: On the storage instances: Four x 6-way stripped volumes, under volume set (VSET/MVFS) VxFS Tuning using /opt/VRTS/bin/vxtunefs aligned_flush_enable=1 discovered_direct_iosz=128m write_nstream=96 read_nstream=96   # /opt/VRTS/bin/vxtunefs -o aligned_flush_enable=1 -o discovered_direct_iosz=128m -o write_nstream=96 -o read_nstream=96 <mount_point>   File system mounted on all client nodes in clustered mode # mount.vxfs -o cluster /dev/vx/dsk/<diskgroup>/<vset> <mount_point>   Results rhel_iotest results: The 5-node test, with 40 cores total, gave us average 155.17 MB per second per physical core for WRITEs and 144.62 MB per second per physical core for READs.   E64-16ds_v4 Read Write Client 1 141.69 154.05 Client 2 143.79 156.41 Client 3 145.68 154.4 Client 4 145.85 153.65 Client 5 146.13 157.34   Test 2: 60 Physical Cores The test infrastructure consisted of the 10 MS Azure instances defined like this:  Four E64-32ds_v4 instances for the SAS clients Six D64s_v3 instances for the IS storage – each with five P60 premium drives. InfoScale 8.0 on RHEL 8.4 was used for the testing.   Architectural Diagram   For the test, the follow tunings were applied: On the storage instances: Five x 6-way stripped volumes, under volume set (VSET/MVFS) VxFS Tuning using /opt/VRTS/bin/vxtunefs aligned_flush_enable=1 discovered_direct_iosz=128m write_nstream=96 read_nstream=96   # /opt/VRTS/bin/vxtunefs -o aligned_flush_enable=1 -o discovered_direct_iosz=128m -o write_nstream=96 -o read_nstream=96 <mount_point>   File system mounted on all client nodes in clustered mode # mount.vxfs -o cluster /dev/vx/dsk/<diskgroup>/<vset> <mount_point>   Results rhel_iotest results: The 4-node test, with 64 cores total, gave us average 129.22 MB per second per physical core for WRITEs and 121.06 MB per second per physical core for READs.   E64-32ds_v4 Read Write Client 1 109.86 128.46 Client 2 113.68 125.27 Client 3 114.28 129.57 Client 4 146.44 133.59   Please note that SAS recommends a minimum of 100 MB per second per physical core for WRITEs and READs.   As you can see, the above InfoScale infrastructure can produce the minimum IO throughput needs of a 40-core and for 64-core SAS Grid application.  Additional testing with more cores showed the minimum of 100 MB per second per physical core for WRITEs and READs is met.   Please reach out to Veritas for more details on InfoScale and how to configure it for optimal performance in MS Azure.   ... View more

Red Hat Engineering is currently converting the Red Hat Tuning Brief, Optimizing SAS on Red Hat Enterprise Linux (RHEL) 6 & 7 Version 1.3, to RHEL Versions 8 (optimizingsasonrhel6and7_2.pdf).     The new guidelines are expected for general distribution by the first of April, 2022.    Until that document is available, please note the following interim advice for RHEL Tuning and Configuration using RHEL 8 for SAS 9:   The majority of the configuration and tuning for RHEL 8 will follow the same RHEL 7 specific guidelines as posted in the current RHEL 6 & 7 Document.  The following exceptions/notes are provided.  If there are any questions/concerns about interim advice, please open a SAS Technical Support ticket for support, and liaison to the R&D CS&E Performance Team.  If Red Hat support is required they will be integrated into the conversation to open a support ticket with them.   Exceptions/Notes:   The Power Management, tuned, udev, ulimits, and multipath advice will remain the same.  Please note that while the tuned files can remain in their current RHEL 7 location and still function, the official ongoing default location for RHEL 8 tuned files will change. The IO Elevator selections that default in RHEL 8 are the Same recommended in RHEL 6 & 7, but have undergone Name Changes: The DEADLINE elevator recommended for use in RHEL 6 & 7 for non-FLASH IO devices, is now called the mq-deadline elevator, and is still recommended. The NOOP elevator recommended for use in RHEL 6 & 7 for FLASH IO Devices, is now called the none elevator, and is still recommended. The new elevators in RHEL 8 & 9 designated as Kyber, and BFQ (replacing CFQ) are Not to be used with SAS 9 or SAS Viya. The advice in Section 2.3.1.1 Concatenated vs. Striped Logical Volumes, will be updated.  For HDD Monolithic Storage systems it will still apply.  For high speed ALL FLASH Storage systems, it is still helpful to performance to follow this advice, but please note that Single LUN LV’s can be adequately performance.  This is dependent on the specific All Flash storage models used, and their ability to offer high LUN Queue depth management.  I.E., in the case of VMWare, VMDKs can be mounted as single LUN LVs on high speed Flash Storage. For the most part, you can apply the RHEL 7 advice in the RHEL 6 & 7 Tuning Guideline for RHEL 8. If you have questions on the exceptions above, please file a Technical Support Ticket to engage the R&D CS&E Performance Team for guidance.   The RHEL 7 Tuning advice for SAS 9 is largely acceptable for SAS Viya Hosts.  Please note that this advice will apply largely to the Viya Worker and Runtime Environment (Compute) nodes.  Some of the advice may vary for Microservices and Controller nodes – please see your Account Team or Technical Support for any implementation specific guidelines for your planned workload.   ... View more