What do you think of when you hear the words “Virtual SAN”? For some, it may mean addressing application latency and infrastructure costs through consolidation. For others, it may be addressing potential single point of failures. Regardless of the use case, Virtual SANs are becoming one of the hottest software-defined storage solutions for IT organizations to maximize storage resources, lower overall TCO, and increase availability of critical applications and data.
This presentation introduces the concept of Virtual SAN and does a technical deep dive on the most common use cases and deployment models involved with a DataCore Virtual SAN solution.
Hello everyone and thank you for attending our webinar today. My name is Jeff Slapp and I am a Technical Product Specialist with DataCore Software. Today we will be continuing our discussion on DataCore Virtual SANs. If you missed the last webinar on Virtual SANs, I would highly recommend checking it out as this webinar will build on the concepts of the previous one. If you did not get a chance to see the previous webinar, no worries, I will do my best to review some of the key concepts in this session.
There will be time for questions at the end of today’s webinar. Please ask your questions in the webinar chat window on the right of your screen. If we run out of time and are not able to answer all of the questions, then we will follow-up via the email you have provided.
There will also be three audience polls taken during this session. Your participation is greatly appreciated. And now with all the housekeeping complete, let’s continue our journey into DataCore Virtual SANs.
[CLICK TO PROCEED]
I’ve provided a brief overview of the topics we will cover today during this session. We will start out by defining what a DataCore Virtual SAN is, what components make up a virtual SAN, review some specific virtual SAN deployment models and use cases, talk about important supporting concepts related to DataCore virtual SANs, and finally closing out with some Q&A.
Again, throughout the session today there will be a series of polls. You will be able to interact with these polls through the webinar interface.
Let’s get started.
[CLICK TO PROCEED]
So what is a DataCore virtual SAN?
DataCore’s Virtual SAN is where SANsymphony-V is used to create high-performance and highly-available shared storage pools using the disks and flash storage in your application servers.
And very simply, it is comprised of…
Two or more physical x86-64 servers with local storage, either running SANsymphony-V directly on the hardware (root partition) or from within a virtual machine.
One of the best ways to understand a DataCore Virtual SAN is to first understand what a traditional DataCore SAN looks like. While both models are different and the reasons for deploying each are different, SANsymphony-V is at the heart of both of them, delivering the very best in enterprise-grade storage functionality and management.
Let’s take a look at them side by side.
[CLICK TO PROCEED]
The first model is a traditional SAN model whereby the application servers, the SANsymphony-V nodes, and the storage devices are distinct units within the stack. This model is ideal for those who have to integrate existing back-end storage systems and/or have hundreds or even thousands of application servers in their infrastructure.
[CLICK TO ANIMATE]
The second model is a virtual SAN model whereby the application servers, the SANsymphony-V software and the local storage devices are converged into a single unit. This model is ideal for those who want to harness the power of their modern application servers while utilizing local host-based flash and disk devices in a consolidated framework.
Let’s take a look at a few benefits realized from deploying virtual SANs.
[CLICK TO PROCEED]
In most SAN environments, there is significant distance and circuity that exist between the main CPU and the storage subsystem (electrically speaking). The additional circuitry introduces delays in the form of context switching which results in measurable transmission latencies. These latencies ultimately result in slower application performance, especially with I/O-intensive applications.
[CLICK TO REMOVE EXTRA HARDWARE]
Within a virtual SAN, the CPU, flash and capacity disk reside as close to each other as possible. This combined with the use of DRAM as high-speed cache, delivers significant application response time improvements.
[CLICK TO PROCEED]
In a typical SAN environment:
The SANs are independent from each other, creating storage silos
They are much more complex, and
Considerably more expensive due to additional hardware and licensing when compared to local server storage.
All of these ultimately contribute to a much higher total operating cost.
[CLICK TO PROCEED]
Virtual SAN, however, unifies all storage under its management into a single pane of glass, reduces overall infrastructure complexity, significantly reduces the amount of hardware involved, and eliminates the storage-system-specific licensing costs.
[CLICK TO PROCEED]
Typical SANs, which may have component-level redundancy, lacks the data-level redundancy needed to achieve true high-availability and continuous data accessibility. This is due to the fact that there is only one copy of the data that exists, and that live-active copy resides on a single storage unit (shown here as Datasets 1, 2, and 3)
[CLICK TO PROCEED]
In a virtual SAN environment, component-level and data-level redundancy are combined to deliver the highest level of data availability. Whether a node is interrupted due to planned maintenance or due to environmental failure, the data will remain intact and accessible to all the applications and users because it exists in multiple places. Additionally, the mirror copies of each dataset can resided on any node you choose and can be easily migrated from one node to another with a few mouse clicks or even automated though scripting.
[CLICK TO PROCEED]
OK, It’s time for our first poll. Carlos?
Now let’s explore some common virtual SAN deployment models.
There are two principle virtual SAN deployment models.
The first is where SANsymphony-V is running in the root partition, on the bare metal, alongside the application. The application could be anything from file services, to mail services, to Hyper-V services. Microsoft clustering services can also be enabled to take advantage of application high-availability since the data will reside on multiple virtual SAN nodes within the cluster.
The second is where SANsymphony-V is running within a virtual machine under control of a server hypervisor. We will focus on a VMware ESX hypervisor scenario for this discussion today, but the virtual machine model can be applied to any hypervisor in the market capable of running a Windows-based virtual machine.
We will only cover general details in this discussion today. Please refer to the DataCore Virtual SAN Design Guide for more information.
Let’s take a look at the root partition model a little closer.
[CLICK TO PROCEED]
In this diagram, I have broken out the primary services into service-planes.
The first service-plane is the DataCore Storage Service Plane. At this point, we simply have any x86-64 bare metal system running Windows Server with DataCore SANsymphony-V installed. A portion of the host RAM is allocated to SANsymphony-V to be used for high-speed cache. We recommend a minimum of 10% of the total available host RAM to be allocated to cache.
Next, the disk and flash that is intended to be used by SANsymphony-V is allocated to SANsymphony-V disk pools. From these disk pools, virtual disks are then created and served back to the local Windows host operating system via the DataCore Loopback Adapter (or via iSCSI if clustering will be used). The key point to recognize here is, now that the local disks are under control of SANsymphony-V, the entire feature set of SANsymphony-V, including high-speed cache, synchronous mirroring, and auto-tiering to name a few, can now be harnessed on the local host and across the entire virtual SAN cluster.
The second service-plane is the Application Services Plane. The application can be anything supported to run on a Windows Server operating system. Again, applications can run independently on each virtual SAN node, or can participate within a Microsoft Cluster across multiple hosts for application high-availability. In either case, the data is protected through synchronous mirroring on multiple hosts within the virtual SAN cluster.
[CLICK TO PROCEED]
Here, we will look a bit closer at running a virtual SAN within a virtual machine infrastructure, under control of a server hypervisor such as VMware ESX. It is important to point out however, that DataCore’s virtual SAN can run within any hypervisor capable of running a Windows Server virtual machine.
Each focus area will blink on the diagram as we proceed through the discussion.
[CLICK TO ANIMATE]
The first step before installing VMware ESX is to configure the physical disks with the RAID configuration you require. Ensure that the disks that are being used for the VMware ESX operating system are separate from those which will run within SANsymphony-V’s disk pool. If you do not have RAID capability on your host, SANsymphony-V can provide those services within the disk pool.
Next proceed with installing VMware ESX on the host. During installation, a local VMware datastore will be created.
[CLICK TO ANIMATE]
Next is to create the SANsymphony-V virtual machine. This virtual machine will reside on the local VMware datastore that was automatically created during installation.
[CLICK TO ANIMATE]
Once the SANsymphony-V virtual machine has been created and SANsymphony-V installed, proceed with presenting the remaining unallocated local host disks to the SANsymphony-V virtual machine. These raw disks will be placed into a SANsymphony-V disk pool.
[CLICK TO ANIMATE]
Once the disk pool is ready, it is time to create some SANsymphony-V virtual disks. These virtual disks will then be presented to the local ESX host, or other virtual SAN nodes within the cluster, via iSCSI. These virtual disks will become VMware Datastores which is where all the virtual machines will reside.
[CLICK TO ANIMATE]
And finally, now that you have created VMware Datastores presented from the local SANsymphony-V virtual machine, you can proceed with creating the rest of the virtual machines needed for your environment.
[CLICK TO PROCEED]
OK, It’s time for our second poll. Carlos?
Now we will review some virtual SAN use cases.
[CLICK TO PROCEED]
Latency-sensitive applications, such as databases, benefit greatly from having their storage services very close to one other. This, combined with the use of DRAM as high-speed cache, which is also very close to the application, results in significant application performance improvements.
[CLICK TO PROCEED]
Virtual SANs can be deployed in branch offices where it doesn’t make sense to have a centralized SAN infrastructure, but where you still may require highly available enterprise services.
Additionally, Virtual SANs can be used at disaster recovery sites to avoid the need to recreate the full production environment at another location, which is extremely expensive to do and offers very low ROI. And with SANsymphony-V’s asynchronous replication feature, you can perform tests of the remote data and applications as often as you like, without interrupting production.
Regardless of whether you deploy a central SAN, a remote office virtual SAN, or a disaster recovery virtual SAN, you will be able to manage these resources from a single pane of glass.
[CLICK TO PROCEED]
DataCore Virtual SANs significantly increase the virtual-desktop-per-host density. In our labs today we have run as many as 300 virtual desktops on a single host. This is made possible because of the high-speed caching SANsymphony-V provides. Additionally, auto-tiering allows you to introduce flash disk on each host and will ensure that the high intensity desktops get access to the high-speed disk when they need it, providing you with an all flash-feel without the all-flash expense.
[CLICK TO PROCEED]
When you are running applications that cannot suffer downtime, then you need synchronous mirroring. Synchronous mirroring provides real-time lock-step mirroring of all data across multiple hosts. In the example above, if node 1 in building 1 was to suffer a catastrophic failure, the data would remain safe and fully accessible on node 2 in building 2. Synchronous mirroring is supported up to 100km.
[CLICK TO PROCEED]
Ok, let’s talk briefly about other important takeaway's when considering DataCore virtual SANs.
[CLICK TO PROCEED]
DataCore is the only vendor that allows unification of both virtual SANs and central SANs across any block-level storage device and any x86-64 server hardware.
[CLICK TO PROCEED]
SANsymphony-V is a complete software-defined storage stack that has developed over the last 16 years.
We are on our 10th generation product with a cross-device set of services.
In this unified software platform we provide everything you need to manage your storage. Many of these are features you’ll find on a modern storage system. Things like thin provisioning, auto-tiering, and snapshots.
DataCore provides all of this functionality in a completely hardware-agnostic form. This enables us to do things that no other vendor can do, like auto-tiering and mirroring across unlike storage systems.
[CLICK TO PROCEED]
DataCore customers report:
up to a 75% reduction in storage costs
up to a 10 time performance increase from the existing storage hardware they have in their environment
up to a 4 time improvement in capacity utilization, and
a 100% reduction in storage-related downtime
DataCore customers also report a 90% decrease in the time they spend on routine storage tasks.
These are real proof points derived from first-hand survey’s of our customer base – verified by a 3rd party, TechValidate who specializes in auditing the results.
[CLICK TO PROCEED]
Curious when to get started with DataCore?
Before your make your next major storage decision, whether a hardware refresh or a brand new purchase.
The same goes if you are looking at flash, SSDs or new types of storage such as DIMM-connected flash.
It also makes sense when expanding your server or desktop virtualization environment.
And certainly as you develop or adjust your business continuity and disaster recovery plan.
[CLICK TO PROCEED]
And now for the last poll of this session. Carlos?
And now I will address the questions that came in during the webinar.
[Stay on this slide to answer them and at the same time keep a reminder of what you presented]