This post was originally published on this siteThis post I will talk about using PowerCLI to run a test failover for VVol-based virtual machines. One of the many ...
This announcement has a lot of fantastic features but one that really excites me is Purity Run, a core architectural innovation accelerator which we will leverage to bring to market some powerful always-on data services, Windows File Services (WFS) being one of these.
Read more below and also take a look at our other blogs as part of this series.
Cloud-Era Flash: “The Year of Software” Launch Blog Series
As covered in our launch blog, FlashBlade TM is our large-scale NFS offering, and the WFS solution is aimed for unified deployments of block and file on FlashArray.
WFS adds robust and advanced file services to FlashArray, and snaps right into the Microsoft management ecosystem. WFS for Purity FA is fully-supported by Pure, and is an ideal solution for file sharing, home directories, collaboration, and VDI user files, and enables you to leverage your existing Microsoft Windows Server license agreement. When it comes to client connectivity, WSF can leverage onboard 10Gbe ethernet ports to serve file shares or additional dedicated ports can be installed.
WFS is based on a Purity-optimized version of Windows Server Standard Edition 2016 (WSE), which runs as an independent instance inside Purity//Run on every controller to form a Windows Cluster to provide application HA. MSFT cluster time-outs and failovers have been optimized to run inside the FlashArray and the provided image is bootstrapped to remove features and functionalities which are native to Purity, for example compression, encryption and deduplication. Furthermore this is fully integrated with our newly introduced flash-optimized ODX implementation which brings blazing fast, transparent, automatic data copy and move services for files. Package creation and optimization happens directly on FlashArray once your WSE ISO has been transferred onto the array over the network.
Installation and setup of the operating systems and cluster setup is fully automated; once the application package is created, set-up takes no longer than 5 minutes. After the install is completed the WFS clustered instances will show up as a new hosts in Purity UI and the App health can be monitored from the Apps tab.
All block storage tasks such as volumes creations, snaps, QoS, replication, monitoring and reporting can be handled just as this were an external host. File administration and configuration is done by leveraging Windows management and API stack.
True to our NDU philosophy we have invested a lot of time making sure the solution is robust and fully HA. For this very reason we run two instances of WFS, one in every controller, and then create a MSFT cluster across the two WFS nodes. This architecture ensure that File Services can continue uninterrupted in case of failure of a single WFS node or a controller failure; furthermore the solution fully supports SMB transparent failover to make file shares continuously available, during failure conditions. When it comes to security, Purity//RUN and FA resources are partitioned to ensure complete isolation between Purity and the Apps, in this case WFS. For maximum protection Purity block level native snapshot technology can be leveraged to protect against ransomware attacks, block volumes snaps are completely isolated and protected from the application and cannot be compromised. As an extra layer of protection we also take regular automated snapshot of the WFS instances for fast recovery from any issues which might happen at the Windows OS layer.
WFS is delivered via Purity //RUN, which in this release reserves a fixed set of resources to be consumed by Apps (WFS in this case), specifically 4 vCPUs and 16GB of Memory per controller.In the future you will be able to choose if you want to allocate less or more resources to WFS. This reservation translates to around 10% of overall available block performance, and what is cool is that you can verify the impact of enabling //RUN on your system by using Pure1 Workload Planner. To put this in layman terms if your system is capable of delivering 100k IOPS at saturation with //RUN enabled it will be able to deliver 90k IOPS. As we did for high-availability we have spent a lot of time doing performance optimizations, to mention a few: we have invented a fast transfer memory queue for efficient exchange of data between WFS and Purity, worked on interrupts and NUMA optimizations and also reduced overall WFS footprint by disabling all those tasks which are offloaded to Purity (deduplication,compression,encryption to mention a few).
Initial testing shows we can sustain over 3,000 concurrent users and plan to increase this further by continuous optimizations and also by allowing you, if you choose, to reserve more system resources to run file services.
Consolidation of file and block is yet another step to the all-flash data center. There has been a lot of excitement around delivering a unified multi-protocol solution to FlashArray. We are seeing some very promising data reduction ratios on file workloads driven by optimizations present in Compression 2.0. Stay tuned for a follow up blog on this very topic.