TECH::Why I prefer NAS over SAN (and why you might, too!)

When thinking of NAS in relation to SAN, it’s just hard to say one is better than the other any more. How does one quantify something like that as “better” in today’s modern abstracted datacenter?

As a Technical Marketing Engineer for NFS, I could certainly think of reasons NAS is better, but even I could make a valid argument for SAN in some instances. Datacenters are not one-size-fits-all and not every nail uses the same hammer.

It’s another classic case of “it depends.”

¯\_(ツ)_/¯

For instance, if your workload uses a single server/cluster and doesn’t need to be accessed by multiple clients at the same time, doesn’t need to worry about ACLs and doesn’t need to be client-agnostic, then SAN might make more sense. But what about NAS?

Wait, aren’t SAN and NAS the same thing?

SAN and NAS are often confused with each other, given they use the same subset of letters in their acronyms and that the general concept is the same – accessing data over a network. In fact, when I’ve asked the question in interviews, people often stumble over what the difference between the two is, and instead, offer the acronym definitions.

SAN = Storage Area Network
NAS = Network Attached Storage

At the surface, they certainly don’t sound very different. However, there are many differences between the two.

• SAN is block-level and leverages SCSI commands. NAS is file-level and leverages standard NFS and SMB protocols.
• SAN can use iSCSI or FCP. NAS uses standard ethernet TCP/IP.
• iSCSI operates at a lower layer (session layer) of the OSI model than NAS does (all the way to application layer).
• FCP uses its own separate OSI-like model.
• NAS is older than SAN. Both had the goal to eliminate Direct Attached Storage (DAS). Both have succeeded.

So, why do I prefer NAS over SAN?

Find out at DataCenterDude.com!

http://www.datacenterdude.com/storage/what-differentiates-nas-from-san/

TECH:: Data ONTAP 8.2.3P3 is now available!

Check it out!

Why Is The Internet Broken?

Data ONTAP 8.2.3P3 has been released. As the NFS TME at NetApp, I am pretty stoked. Get it here:

http://mysupport.netapp.com/NOW/download/software/ontap/8.2.3P3

This is an update to both 7-Mode and clustered Data ONTAP. Keep in mind that minor releases (such as 8.2.x) are immediately considered GA, so there is no RC for minor releases. They are essentially patch rollups with minimal new features.

The update contains:

• Name services resiliency improvements (both modes)
• SAN resiliency improvements
• New platform support
• NSE support for SnapLock in 7-Mode
• Storage and Disk health monitoring services
• Role-based access for SnapMirror in clustered Data ONTAP
• New PAM card support
• Windows NFSv3 client support for clustered Data ONTAP

If you are running NAS and are already on a 8.2.x release, UPGRADE AS SOON AS POSSIBLE. Lots of good NAS features/fixes for both 7-mode and cDOT.

If you are on a 8.1.x or prior release, consider/plan on upgrading, as it will be…

View original post 1,512 more words

TECH::How to set up Kerberos on vSphere 6.0 servers for datastores on NFS

For a more in-depth, updated version:

Kerberize your NFSv4.1 Datastores in ESXi 6.5 using NetApp ONTAP

In case you were living under a rock somewhere, VMWare released vSphere 6.0 in March. I covered some of my thoughts from a NFS perspective in vSphere 6.0 – NFS Thoughts.

In that blog, I covered some of the new features, including support for Kerberized NFS on vSphere 6.0. However, in my experience of setting up Kerberos for NFS clients, I learned that doing it can be a colossal pain in the ass. Luckily, vSphere 6.0 actually makes the process pretty easy.

TR-4073: Secure Unified Authentication will eventually contain information on how to do it, but I wanted to get the information out now and strike while the iron is hot!

What is Kerberos?

I cover some scenarios regarding securing your NFS environment in “Feeling insecure about NFS?” One of those I mention is Kerberos, but I never really go into detail about what Kerberos actually is.

Kerberos is a ticket-based authentication process that eliminates the need to send passwords over the wire in text format. Instead, passwords are stored on a centralized server (known as a Key Distribution Center, or KDC) that issues tickets to grant tickets for access. This is done through varying levels of encryption, which is controlled via the client, server and keytabs. Right now, the best you can do is AES, which is the NIST standard. Clustered Data ONTAP 8.3 supports both AES-128 and AES-256, by the way. 🙂

However, vSphere 6.0 supports only DES, so…

Again,  TR-4073: Secure Unified Authentication covers this all in more detail than you’d probably want…

Kerberize… like a rockstar!

In one of my Insight sessions, I break down the Kerberos authentication process as a real-world scenario, such as buying a ticket to see your favorite band.

• A person joins a fan club for first access to concert tickets
  • Ticket Granting Ticket (TGT) issued from Key Distribution Center (KDC)
• A person buys the concert ticket to see their favorite band
  • TGT used to request Service Ticket (ST) from the KDC
• They pick the ticket up at the box office
  • ST issued by KDC
• They use the ticket to get into the concert arena
  • Authentication
• The ticket specifies which seat they are allowed to sit in
  • Authorization; backstage pass specifies what special permissions they have

Why Kerberos?

One of the questions you may be asking, or have heard asked is, “why the heck do I want to Kerberize my NFS datastore mount? Doesn’t my export policy rule secure it enough?”

Well, how easy is it to change an IP address of an ESXi server? How easy is it to create a user? That’s really all you need to mount NFSv3. However, Kerberos requires a user name and password to get a ticket, interaction with a KDC, ticket exchange, etc.

So, it’s much more secure.

Awesome… how do I do it?

Glad you asked!

After you’ve set up your KDC and preferred NFS server to do Kerberos, you’d need to set the client up. In this case, the client is vSphere 6.0.

Step 1: Configure DNS

Kerberos needs DNS to work properly. This is tied to how service principal names (SPNs) are queried on the KDC. So, you need the following:

• Forward and reverse lookup records on the DNS server for the ESXi server
• Proper DNS configuration on the ESXi server

Example:

Step 2: Configure NTP

Kerberos is very sensitive to time skew. There is a default of 5 minutes allowed between client/server/KDC. If the skew is outside of that, the Kerberos request will fail. This is for your security. 🙂

Step 3: Join ESXi to the Active Directory Domain

This essentially saves you the effort of messing with manual configuration of creating keytabs, SPNs, etc. Save yourself time and headaches.

Step 4: Specify a user principal name (UPN)

This user will be used by ESXi to kinit and grab a ticket granting ticket (TGT). Again, it’s entirely possible to do this manually and likely possible to leverage keytab authentication. But, again, save yourself the headache.

Step 5: Create the NFS datastore for use with NFSv4.1 and Kerberos authentication

You *could* Kerberized NFSv3. But why? All that gets encrypted is the NFS stuff. NLM, NSM, portmap, mount, etc don’t get Kerberized. NFSv4.1 encapsulates all things related to the protocol, so encrypting NFSv4.1 encrypts it all.

Enter the server/datastore information:

Be sure you don’t forget to enable Kerberos:

After you’re done, test it out!

TECH:: Amazon AWS: File services enter the cloud!

This week at Amazon AWS Summit, the new Amazon Elastic File System (EFS) was announced.

From the EFS product page:

Amazon Elastic File System (Amazon EFS) is a file storage service for Amazon Elastic Compute Cloud (Amazon EC2) instances. Amazon EFS is easy to use and provides a simple interface that allows you to create and configure file systems quickly and easily. With Amazon EFS, storage capacity is elastic, growing and shrinking automatically as you add and remove files, so your applications have the storage they need, when they need it.

Amazon EFS supports the Network File System version 4 (NFSv4) protocol, so the applications and tools that you use today work seamlessly with Amazon EFS. Multiple Amazon EC2 instances can access an Amazon EFS file system at the same time, providing a common data source for workloads and applications running on more than one instance.

This is HUGE news – and not just for Amazon. As the Technical Marketing Engineer for NFS at NetApp, you can imagine how excited I am about this.

Why?

Amazon has just validated using NAS in the cloud.

For the longest time, cloud access has been limited to object-based storage and REST APIs. Now, users can access data via file-based NFSv4 through Amazon Web Services. It is time to…

To read more, see my post on DataCenterDude.com!

Amazon Announces EFS

TECH::New DataCenterDude post – The Secret Origins of RTFM

It’s 10:30AM. The blue, translucent Outlook mail notification wafts at the bottom of our fearless support guy’s screen.

“Hey! Sorry to bother you, but how do I….”

Our fearless admin’s eyes roll deep into the back of his eye sockets as he emits a loud, exasperated sigh. He knows it’s in the manual – he helped write it. But no one seems to read it. He feels his efforts have been wasted.

But today, our fearless admin has a plan. Through the miracles of modern science and some quick Google searches, he has found a secret formula that would merge his mind into anyone that emails him to ask questions. They would be under his control and would instantly think to look for the answers themselves. All he needs is a bolt of lightning to complete the transformation.

The storm clouds swirl outside of his datacenter. He hooks a metal conducting rod up to a set of copper wires and applies the clamps to his nipples. The air is crisp and smells of electricity. The hairs on the back of his neck stand on end.

CRACKKKKKLLLEEEEEE!!!!

The bolt strikes the metal rods and our fearless admin screams in agony! The smell of electricity becomes the smell of burnt hair. On a table next to him, a bottle of unconsumed serum sits next to a set of instructions.

1. Drink serum.
2. Attach cables to toes.

Our fearless admin sits in the chair, drooling, mumbling.

The above scenario is one of the most contentious parts of anyone’s job in IT. We lament over and over about how no one reads anymore, but we are also often just as guilty – victims of our own hubris and overconfidence. In our own minds, we’re somehow annoyed by the very job we were hired to do. Help people solve problems. But sometimes it just touches the nerve, especially in situations where you’ve already explained how to fix it, and even more especially when you’ve already explained how to fix it to the same person.

For more, check out the full post on DataCenterDude.com!