{"id":15367,"date":"2013-08-28T13:34:00","date_gmt":"2013-08-28T12:34:00","guid":{"rendered":"https:\/\/aidanfinn.com\/?p=15367"},"modified":"2013-08-28T13:34:00","modified_gmt":"2013-08-28T12:34:00","slug":"putting-the-scale-into-the-scale-out-file-server","status":"publish","type":"post","link":"https:\/\/aidanfinn.com\/?p=15367","title":{"rendered":"Putting The Scale Into The Scale-Out File Server"},"content":{"rendered":"

Why did Microsoft call the \u201chighly file server for application data\u201d the Scale-Out File Server (SOFS)?\u00a0 The reason might not be obvious unless you have lots of equipment to play with \u2026 or you cheat by using WS2012 R2 Hyper-V Shared VHDX as I did on Tuesday afternoon \"Smile\"<\/p>\n

The SOFS can scale out in 3 dimensions.<\/p>\n

0: The Basic SOFS<\/h4>\n

Here we have a basic example of a SOFS that you should have seen blogged about over and over.\u00a0 There are two cluster nodes.\u00a0 Each node is connected to shared storage.\u00a0 This can be any form of supported storage in WS2012\/R2 Failover Clustering<\/a>.<\/p>\n

\"image\"<\/a><\/p>\n

1: Scale Out The Storage<\/h4>\n

The likely bottleneck in the above example is the disk space.\u00a0 We can scale that out by attaching the cluster nodes to additional storage.\u00a0 Maybe we have more SANs to abstract behind SMB 3.0?\u00a0 Maybe we want to add more JBODs to our storage pool, thus increasing capacity and allowing mirrored virtual disks to have JBOD fault tolerance.<\/p>\n

\"image\"<\/a><\/p>\n

I can provision more disks in the storage, add them to the cluster, and convert them into CSVs for storing the active\/active SOFS file shares.<\/p>\n

2: Scale Out The Servers<\/h4>\n

You\u2019re really going to have to have a large environment to do this.\u00a0 Think of the clustered nodes as SAN controllers.\u00a0 How often do you see more than 2 controllers in a single SAN?\u00a0 Yup, not very often (we\u2019re excluding HP P4000 and similar cos it\u2019s weird).<\/p>\n

Adding servers gives us more network capacity for client (Hyper-V, SQL Server, IIS, etc) access to the SOFS, and more RAM capacity for caching.\u00a0 WS2012 allows us to use 20% of RAM as CSV Cache and WS2012 R2 allows us to use a whopping 80%!<\/p>\n

\"image\"<\/a><\/p>\n

3: Scale Out Using Storage Bricks<\/h4>\n

GO back to the previous example.\u00a0 There you saw a single Failover Cluster with 4 nodes, running the active\/active SOFS cluster role.\u00a0 That\u2019s 2-4 nodes + storage.\u00a0 Let\u2019s call that a block, named Block A.\u00a0 We can add more of these blocks \u2026 into the same cluster.\u00a0 Think about that for a moment.<\/p>\n

EDIT: When I wrote this article I referred to each unit of storage + servers as a block. \u00a0I checked with\u00a0Claus Joergensen of Microsoft and the terms being used in Microsoft are\u00a0storage bricks or storage scale units. \u00a0So wherever you see “block” swap in storage brick or storage scale unit.<\/em><\/p>\n

\"image\"<\/a><\/p>\n

I\u2019ve built it and it\u2019s simple.\u00a0 Some of you will overthink this \u2026 as you are prone to do with SOFS.<\/p>\n

What the SOFS does is abstract the fact that we have 2 blocks.\u00a0 The client servers really don\u2019t know; we just configure them to access a single namespace called \\Demo-SOFS1 which is the CAP of the SOFS role.<\/p>\n

The CSVs that live in Block A only live in Block A, and the CSVs that live in Block B only live in Block B.\u00a0 The disks in the storage of Block A are only visible to the servers in Block A, and the same goes for Block B.\u00a0 The SOFS just sorts out who is running what CSV and therefore knows where share responsibility is.\u00a0 There is a single SOFS role in the entire cluster, therefore we have the single CAP and UNC namespace.\u00a0 We create the shares in Block A in the same place as we create them for Block B .. in that same single SOFS role.<\/p>\n

A Real World Example<\/h4>\n

I don\u2019t have enough machinery to demo\/test this so I fired up a bunch of VMs on WS2012 R2 Hyper-V to give it a go:<\/p>\n