The first post in this two-part series was about the general new feature of VMware vCenter Site Recovery Manager 6.0 and Storage DRS. Read about it here. In this post, I am going to take a bit more of a specific look at this when it comes to the FlashArray and our Storage Replication Adapter (SRA).
Non-technical post here. Some information though for an upcoming event:
Beginning June 1st, Pure Storage will be hosting events in 50+ cities all over the world to make some exciting announcements concerning the future of flash in the datacenter as well as a sweet new product launch. We’ll be talking about a vision that is transforming the storage industry and more. I highly recommend registering for one in a city near you!
Here is another “look what I found” storage-related post for vSphere 6. Once again, I am still looking into exact design changes, so this is what I observed and my educated guess on how it was done. Look for more details as time wears on.
***This blog post really turned out longer than I expected, probably should have been a two parter, so I apologize for the length.***
Like usual, let me wax historical for a bit… A little over a year ago, in my previous job, I wrote a proposal document to VMware to improve how they handled XCOPY. XCOPY, as you may be aware, is the SCSI command used by ESXi to clone/Storage vMotion/deploy from template VMs on a compatible array. It seems that in vSphere 6.0 VMware implemented these requests (my good friend Drew Tonnesen recently blogged on this). My request centered around three things:
- Allow XCOPY to use a much larger transfer size (current maximum is 16 MB) a.k.a, how much space a single XCOPY SCSI command can describe. Things like Microsoft ODX can handle XCOPY sizes up to 256 MB for example (though the ODX implementation is a bit different).
- Allow ESXi to query the Maximum Segment Length during an Extended Copy (XCOPY) Receive Copy Results and use that value. This value tells ESXi what to use as a maximum transfer size. This will allow the end user to avoid the hassle of having to deal with manual transfer size changes.
- Allow for thin virtual disks to leverage a larger transfer size than 1 MB.
The first two are currently supported in a very limited fashion by VMware right now, (but stay tuned on this!) so for this post I am going to focus on the thin virtual disk enhancement and what it means on the FlashArray.
VMware vRealize Log Insight is a product I have been quite fond of since it first came out–I liked it for a variety of reasons–one is the simplicity of use. As far as VMware’s entire management suite, it is the easiest to install/configure and understand how to use. You can really become an accomplished user in a day. Anyways, I finally got around to updating the Pure Storage FlashArray Content Pack to expand support for version 2.5 and also leverage some new functionality from Purity syslog messages.
I jumped on a call the other day to talk about iSCSI setup for a new FlashArray and the main reason for the discussion had to do with co-existence of a pre-existing array from another vendor. They were following my blog post on iSCSI setup and things didn’t quite match up.
To setup multi-pathing (the recommended way) for Software iSCSI is to configure more than one vmkernel port that each have exactly one active host adapter (physical NIC). You then add those vmkernel ports to the iSCSI software adapter and the iSCSI adapter will then use those specific NICs for I/O transmission and load-balance across those ports.
The first step prior to provisioning storage on the FlashArray is to actually create the host records on the array itself. These records, in their most basic form, are just names of hosts with associated WWNs or IQNs. Pretty simple process in general, but as these VMware clusters get larger and larger (vSphere 6.0 now allows 64 hosts per cluster) scripting this configuration becomes a bit more appealing. Granted, this is a one-off operation, but still saves you from a tedious task. So I wrote one. This script also integrates setting the best practices on the ESXi hosts in the cluster and in the case of iSCSI adds the FlashArray iSCSI ports as a target on the host software iSCSI adapters.
I recently posted the process of configuring iSCSI on ESXi with the Pure Storage FlashArray. One of the things I left out is (optional) CHAP security configuration. It is a pretty straight forward process but worth writing down to save anyone who wants to configure it a few document cross-reference checks.
I’ve have been working with VMware’s vCenter Site Recovery Manager since the tail end of the 1.x release and I have to say this is the most excited I have been about a Storage Replication Adapter release that I can remember. Since I started with Pure in late April 2014 I have been working with our development team and product management to design and shape this initial release of the Pure Storage SRA. I have to say it has been a blast–a really great team that does some really amazing work! It is now officially approved and posted on VMware’s compatibility guide and SRA download site:
The vSphere Web Client Plugin for the Pure Storage FlashArray has been updated and released and it is the largest update to the plugin since, well, it was first released. A lot of feature enhancements–the majority focused on integrating local and remote replication management into the plugin. Our long term goal is to offer feature parity of FlashArray management with the plugin as compared to our own GUI. It is getting close. Let’s take a look at the new features.
Pure Storage announced last week our very first converged architecture offering appropriately named FlashStack. The initial release of FlashStack is built off of Cisco hardware (UCS of course) and the FlashArray. We have two reference architectures presently, one for VMware Horizon View and one for general purpose VMware vSphere environments (choose your own guest OSes). My colleague Ravi Venkat (@ravivenk) architected the View ref arch, while I focused on the general vSphere one. In this blog post I am going to overview what we did with the vSphere ref arch. For more information on either, refer to the respective reference architecture white papers at the usual place: