Understanding Cloud Storage- SAN, NAS, and DAS

While the cloud storage technology continues to grow many consumers and businesses are beginning to adopt the new technology. Cloud storage is data storage which is available over a network. You can access this network to pull or input your information.

Since the explosion of cloud computing and cloud shared storage requirements, these TLA’s (Three Letter Acronyms) SAN, NAS, and DAS get thrown around quite frequently.  If you find yourself hearing SAN, NAS, or DAS often and are not quite sure what they mean, this blog is for you!

Essentially SAN, NAS, and DAS describe the exact same thing: a storage box that exists as a separate device where your servers interconnect.  These devices and interconnects make up what is commonly called the SAN, the Storage Area Network.  You’ll have a box of hard drives containing your storage, and a network that connects your servers to the storage. NAS and DAS are most often used to describe the method of connection your servers will use to connect to the storage.

Network Attached Storage (NAS) are storage devices that present the storage over an IP network, CIFS and NFS are most commonly used. Your servers will use the connection to access the storage.  This term is slightly ambiguous as there are also a lot of very low end consumer devices that are also referred to as NAS devices. However, they are designed to provide storage to a home network environment and lack the performance and redundancy features that are standard in higher level devices.

Direct Attached Storage (DAS) connects directly to your servers using some form of a Host Bus Adapter (HBA) installed in the servers. DAS gives your servers the lowest level access to the storage. Which means it’s a more simple connection. It’s basically attached right to your hardware. This yields better performance because there are less layers of abstraction.

When choosing to use SAN, NAS, or DAS one isn’t significantly better. But there are some key differences based on the above descriptions.  Network attached SANs have advantages in versatility, since they can use standard networking technology to connect to your servers.  SANs make it easier to connect a large number of servers to the storage device.  This versatility can come at the cost of performance though. Even gigabit Ethernet can become a bottleneck depending on how much data you need to push through the network.

DAS devices can provide more performance than NASs, since they use a high performance direct SAS connection.  The downside to these devices is that depending on the specific device and configuration you may be limited to the number of servers you can directly connect.

The comforting part of selecting a SAN device is that there are a massive number of possibilities so that there will always be a solution that fits your capacity, performance, and expandability needs.

Cloud storage can give you many different options whether it is SAN, NAS or DAS. However make sure to read the service-level agreements (SLA’s) and understand exactly what you are getting with your storage option.

Bigger, Better, Stronger, Faster! vCenter ESXi 5.0! Cluster HA- Bring it!

While there are many new changes in VMWare ESXi 5.0, like Image Builder, Auto Deploy/Central Management, Firewall Changes, USB 3 Support and hardware upgrades, Today I’m going to highlight Cluster HA.

In vCenter 5.0 VMware Cluster HA functionality has been fully revamped.  The clunky Automated Availability Manager (AAM) used in 4.X and below is now replaced by Fault Domain Manager (FDM).  AAM had many quirks and limitations some of them being that it only used the management interface as the heartbeat communication for nodes in the cluster. Troubleshooting it when it broke was a headache because it wrote too many log files all over the place.  AAM could also only have 5 cluster masters which were elected when the first 5 ESXi hosts joined the cluster, this could not be exceeded and if the hosts needed to change it had to be done manually via configuration files.  This caveat would need to be taken into consideration in your infrastructure design so that all of the masters didn’t reside in the same enclosure, DC, running of the same power, etc…

FDM is far more resilient to host failures and isolations.  It has a new cluster master election process which assigns a single node as the cluster master; if that node dies any node inside cluster can rerun the election process and assign a new master inside the cluster.  If host isolation occurs the isolated hosts can function on their own and elect a new master.  Once the hosts can communicate with one another and there are multiple masters present in the cluster the election process will begin and a single master will be elected once again.  FDM now uses the management interfaces as a heartbeat but also the storage network (datastore) for heart beat communication.  If you bring down your management switches for your ESXi servers for maintenance/failure the cluster can still communicate on the storage network not causing any re-election inside the cluster or any sort of freak out.  FDM also has a single log file (/var/log/fdm.log) for troubleshooting and supports syslog for centralized log gathering and possible monitoring functionality. FDM is exciting news for VMware admins and end users alike!

I hope that you find the write ups on cluster HA and vCenter Storage helpful. If you’d like more information on any new vCenter features please comment below.

Bigger, Better, Stronger, Faster! vCenter / ESXi 5.0! SDRS and Profile Driven Storage – Bring it!

While there are many new changes in VMWare ESXi 5.0, like Image Builder, Auto Deploy/Central Management, Firewall Changes, USB 3 Support and hardware upgrades, Today I’m going to highlight Storage DRS and Profile Driven Storage.

With vCenter 5.0 comes the introduction of Storage Distributed Resource Scheduler (SDRS) and Profile Driven Storage.  It is common practice to implement standard VMware DRS inside your VMware cluster one would load balance your VMs (virtual machines) based upon CPU and Memory usage.  The new feature within vCenter 5.0, SDRS, uses the same ideology but at the vSphere storage level.

SDRS monitors datastore capacity and disk latency metrics and will Storage vMotion VMs to a better suited storage (datastore’s).  This reduces administrative overhead for the VMware admin. It will help mitigate situations where VMs run out of space and get paused or are running poorly due to insanely high disk latency on the disk subsystem.

Profile Driven Storage is another slick new feature that allows you to specify Storage SLAs on a VM level to ensure that performance is never impacted.  vSphere APIs for Array Awareness (VASA) integrates with the underlying disk array and allows vCenter to understand the type of disk groups and disk tiers that are available to the host.  vCenter will work with the array on moving the VM to the appropriate physical spindles or SSDs using SvMotion after it has been configured in the Storage Profile.  If VASA is not available for your array you can manually configure your tiered storage by using different datastores for different tiers (e.g. EMC01-SSDs-DG#12).

SDRS and Profile Driven Storage combined with VASA will help in ensuring constant storage performance for mission critical VMs. Stayed tuned to www.blog.inetu.net for the next highlighted feature of vCenter/ESXi 5.0.

What Happens When the Server Underneath My Cloud Fails?

When many people think of the Cloud, they think that their application is running on a nebulous collection of resources that’s impervious to hardware failures.  Despite a lot of the marketing material in the industry, this just isn’t the case.  Beneath every Cloud there is hardware, and when that hardware fails, the results to some Clouds can be devastating.

When every server is an island

Many Clouds (like Rackspace’s) use local storage on each server in the Cloud.  When a server in this kind of Cloud fails, your virtual machine goes down with it.  Your VM can only be brought back online when the physical server is up and running again (or it’s restored from a backup).  If you’re using Amazon’s EC2 Cloud without Elastic Block Storage, your VM’s data is gone forever  if the physical server fails!  In both cases, this can mean a whole lot of downtime for you and your application.

Enter Shared Storage

Thankfully, there’s a solution to this problem.  The INetU Gated Community Cloud™ does things a bit differently.  We store all of the data from your virtual machine on an enterprise-grade SAN that can be accessed by other physical servers in the Cloud.  If the physical server that your VM is on fails, your VM is powered up on a different physical host in minutes.  To your virtual machine and application, it simply looks like a reboot.

That begs the question—why isn’t everyone doing this?  Before I answer that, I want to point out that many enterprises with internal Clouds do use a SAN to store their critical virtual machines.  Like most good things, enterprise grade SANs don’t come cheap, and many Cloud providers decide to cut this corner in order to save a few dollars.  Can your business afford to cut this corner?  For a mission critical site or application, the answer is very often a resounding “No”!

INetU Introduces- Shared SAN Storage

INetU Managed Hosting is pleased to announce our new Shared SAN Storage solution!

INetU currently supports a variety of SAN, DAS and NAS solutions to meet each client’s needs. We consult with you in the pre-sales process to select the right storage device, whether that is an EMC SAN, a Net App SAN, a Dell MD3200 or something else. We have introduced a new option for clients who want to get started with database clustering, but do not have the budget for their own dedicated SAN, NAS or DAS: Shared SAN Storage. Clients are able to get dedicated LUNs on our high performing multi-tenant EMC SAN at an affordable price, with storage plans customized to suit your project.

WHAT IS SAN?

Read the full post »

©1996-2011 INetU Inc, All Rights Reserved.