SoftNAS® Cloud Storage Performance
Trust Buurst’s SoftNAS for your cloud storage performance needs. Eliminate cloud application data bottlenecks with SoftNAS.
Cloud Storage Performance Challenges
Users expect high levels of computing performance regardless of the location of the application being on or off premises. To meet this requirement, most cloud-based applications are run with high amounts of compute power. Unfortunately, this solution doesn’t solve the largest bottleneck found in cloud deployment, cloud storage.
Without a NAS solution supporting cloud storage applications will respond unpredictably causing support issues, performance degradation, and low user satisfaction. SoftNAS provides a complete solution for these challenges in terms of performance, storage usage, and the ability to manage data to lower overall cloud storage expenses.
SoftNAS utilize L1 and L2 cache. SoftNAS automatically uses ½ of VM RAM as an L1 cache. You can also configure SoftNAS to use NMVE or SSD disk per storage pool for additional cache performance.
Many customers purchase additional managed storage to obtain an increase in access or pay additional premiums to the cloud provider for provisioned IOPS or throughput. The additional costs for wasted storage space or expensive access are merely an attempt to “tape” over a problem.
Why SoftNAS for your Cloud Storage Performance Needs?
SoftNAS provides direct connectivity to cloud storage providing a private connection to resources owned by your organization. This eliminates the managed storage problems of inconsistent performance by noisy neighbors. In addition, SoftNAS adds value by placing data in the most appropriate location for increased application performance.
Tune SoftNAS for Customized Cloud Storage Performance
SoftNAS offers customers four unique levers to properly configure the performance of a cloud-based application with a dedicated cloud-storage channel.
SoftNAS Instance Settings
SoftNAS can customize the virtual machine settings to provide additional performance. Changing CPU, RAM, and Network Speed on the VM allows SoftNAS to increase access rates for the caches, overall throughput, and IOPS.
Use Default Client Protocols
SoftNAS can use multiple protocols for a single volume. The default protocol for Linux is NFS – Windows is CIFS and both operating systems can access storage through iSCSI. Although Windows can connect to storage with NFS, it is best to use default protocols, as Windows NFS is notoriously slow. With workloads such as SQL, iSCSI would be the preferred protocol for database storage.
Utilize L1 and L2 Cache
SoftNAS automatically uses half of system RAM as an L1 cache and configuration options are available to use NMVE or SSD disk per storage pool for additional cache performance.
SoftNAS overall performance is increased by having dedicated storage attached directly to SoftNAS and a dedicated connection to the client, coupled with dedicated cache and CPU for rapid data transfers.
SoftNAS vs AWS EFS Comparing Throughput MiB/s Performance
A Linux FIO server was used to perform a throughput evaluation of SoftNAS vs EFS. With a cloud storage capacity of 768 GiB, 3.5 TiB, and a test configuration of 64KiB, 70% read and 30% write, the SoftNAS was able to outperform AWS EFS MiB/s in both sequential and random read/write.
SoftNAS vs AWS EFS Comparing Throughput IOPS Performance
A Linux FIO server was used to perform an IOPS evaluation of SoftNAS vs EFS. With a cloud storage capacity of 768 GiB, 3.5 TiB, and a test configuration of 64KiB, 70% read and 30% write, the SoftNAS was able to outperform AWS EFS IOPS in both sequential and random read/write.
SoftNAS vs Amazon EFS Comparing Latency Performance
A Linux FIO server was used to perform a latency evaluation of SoftNAS vs EFS. With a cloud storage capacity of 768 GiB, 3.5 TiB, and a test configuration of 64KiB, 70% read and 30% write, the SoftNAS was able to outperform AWS EFS latency in both sequential and random read/write.
Cloud Storage: Delivering on a performance priority
One of the top priorities for Cloud architects is achieving high performance from applications. As we move more applications to the cloud, CPU, RAM, and fast networks are plentiful. However, storage rises to the top of the list as the cause for Cloud application bottlenecks.
Cloud Storage Performance Use Cases
Common Scenarios and Best Practices
High-performance on-premise storage
For any high-performance on-premise use case, be sure to deploy an adequate amount (e.g., 64 GB or more) of write log (ZFS “ZiL”) and RAM (plus read cache (ZFS “L2ARC”) to absorb the high level of 4K block I/O for best results). For workloads with predominately small (less than 128K) reads and writes, making use of RAM, write log and read cache is critical to achieving maximum throughput, as ZFS block I/O occurs in 128K block I/O chunks. Windows also defaults to 4K blocks.
Virtual Desktops performance
Virtual desktops benefit greatly from all the cache memory, level 2 caching, and high-speed storage available, because many performances lags quickly become visible as users launch applications, open and save files, etc. Caching also helps alleviate “login storms” and “boot storms” that occur when a large number of simultaneous users attempt to log in first thing in the morning. For these situations, a combination of local caching (on each VDI server), combined with appropriate caching for user profiles and applications can yield excellent results.
Windows Workloads performance
One approach that works well for a broad range of applications is to use a combination of SAS and SATA drives – using SSD for read cache/write log (always configure write logs as mirrored pairs in case a drive fails). SATA drives provide very high densities in a relatively small footprint, which is perfect for user mass storage, Windows profiles, Office files, MS Exchange, etc. SQL Server typically demands SAS and/or SSD for best results, due to the high transaction rates involved. Exchange can be relatively heavy on I/O when it’s starting up, but since it reads most everything into memory, high-speed caching does little to help run-time performance after initial startup.