Home > Blogs > VMware vSphere Blog

vCloud Suite – vSphere Storage Appliance (VSA) 5.1 Considerations for Successful Brownfield Deployments – Part II

The second part of this blog series is focused around the vSphere Storage Appliance (VSA) 5.1 shared storage architecture as well as the configuration process and capabilities provided for Brownfield deployments. Some of the key values provided by the vSphere Storage Appliance (VSA) 5.1 are around new capabilities shared storage capabilities such as dynamic storage allocation. This new capability makes it possible to deploy vSphere Storage Appliance (VSA) 5.1 solution into already existing vSphere infrastructures with running virtual machines.

The vSphere Storage Appliance (VSA) 5.1 shared storage architecture is design to support  two or three node cluster configurations which are collectively known and identified as a VSA Storage Cluster. All members of the VSA Storage Cluster will host an instance of the VSA Appliance which will use the available space on the hosts local disks or direct attached storage in order to present them as a single mirrored NFS volumes per hosts. The mirrored NFS volume are then presented to all members of the VSA cluster which are managed by vCenter Server.

Three Node vSphere Storage Appliance (VSA) 5.1 Brownfield Logical Architecture

Before you get to the vSphere Storage Appliance (VSA) 5.1 storage configuration settings the VSA Installer needs to complete all the requirement validation check points process as discussed in part I of this blog series. As previously mentioned, before jumping into the storage configuration settings and recommendations, let’s pick up where part I of the blog series left off, network configurations. The vSphere Storage Appliance (VSA) 5.1 network configuration requirements are very strict in terms of their naming convention and NIC configurations as previously discussed in part 1. The VSA Installer requires configuration for the following network segments:

  • VSA Cluster Management
  • VSA-Front End
  • VSA-Back End

The vSphere Storage Appliance (VSA) 5.1 network configuration requires a certain range and number of IP addresses. The total number of IP addresses needed is defined by the number of hosts that will be used (two or three) by the VSA Cluster and whether or not DHCP will also be used.

VSA Management Network Configuration

The VSA Cluster IP Address requires the assignment of a static IP address. This address is assigned to the member of the VSA Cluster who holds the leader role in the cluster. An option not illustrated above is the VSA Cluster Service (VSACS) IP address. That option is only available in two node cluster configurations. Neither one of them should be configured with private subnet IPs or an IP range that is not accessible by the production (VM Network) network.

VSA Cluster Members Network Configuration

The cluster members have three different type of IP requirements. Both, the Management IP Addresses which are used for the management networks of the VSA Cluster members and the Datastore IP Addresses which are used for the NFS volumes that are exported as the VSA datastores require static IP addresses. The vSphere Feature IP Addresses which are used to access the hosts (ESXi) feature networks can be dynamically or statically assigned. VLAN IDs can be used and defined if the network has been logically isolated. The use of VLAN IDs is not a requirement for the use of vSphere Storage Appliance (VSA) 5.1. The remaining members of the VSA cluster require the same type of unique configuration as the one illustrated above.

Now to the storage configuration section. In Brownfield deployments virtual machines are stored and running on the hosts local VMFS datastores. The vSphere Storage Appliance (VSA) 5.1 Installer is now able to detect the currently utilized capacity by running virtual machines as well as the remaining capacity on the local VMFS datastores. The remaining capacity can now be present it to the VSA Appliances to use as shared storage.

VSA Storage Capacity Configuration

Initially, I recommend adding enough storage capacity from the VSA Installer to support the migrations of locally stored virtual machines. After the shared storage has been configured, the remaining virtual machines running on local VMFS storage can be migrated to the VSA Cluster shared storage resources, using either cold migration (virtual machines powered off) or VMware vSphere Storage vMotion.

The disks formatting option presented is based on the following two formats:

  • Format disks on first access (Thin-Provisioned)
  • Format disks immediately (Zeroed-Thick Provisioned)

Choosing to format the disks immediately will take significantly longer depending on the storage capacity configured. The obvious benefit of choosing to format disks on first access is the ability to overprovision the storage capacity and possibly get greater use of the storage, but this comes with some management overhead cost as closer monitoring will be required in order to avoid issues with running out of storage capacity.

VSA Format Disks Options

All of the virtual machines running on local VMFS datastores with the exception of one can be migrated to the VSA Cluster newly configured NFS shared volumes. The vCenter Server/VSA Manager cannot be migrated to the VSA Cluster storage resource as it is not recommended or supported. The vCenter Server must remain on the local VMFS storage of one of the cluster members.

After the running virtual machines have been migrated off the hosts local VMFS datastores, the new vSphere Storage Appliance (VSA) 5.1 “Increase Storage” feature can be used to reclaim the available local space and dynamically add that storage capacity to the VSA Cluster NFS shared volumes.

vSphere Web Client VSA Cluster Properties

The Increase Storage wizard is located on the top banner of the VSA Cluster Properties of the VSA Manager interface. The VSA Manager is accessible in the vSphere Web Client under the Datacenters Classic Solutions tab as illustrated above.

Increase VSA Cluster Storage Capacity

The new features and capabilities introduced with vSphere Storage Appliance (VSA) 5.1 such as the dynamic allocation of storage remove some of limitations that were imposed by earlier releases of vSphere Storage Appliance (VSA) 1.0. The new features and capabilities in the vSphere Storage Appliance (VSA) 5.1 make it possible to successfully deploy the solution onto any SMB/ROBO virtual infrastructure.

vCloud Suite – vSphere Storage Appliance (VSA) 5.1 Brownfield Deployments Blog Series: 

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @PunchingClouds

This entry was posted in Uncategorized and tagged , , on by .
Rawlinson Rivera

About Rawlinson Rivera

Rawlinson is a Principal Architect working in the Office of CTO for the Storage and Availability Business Unit at VMware. Focus on defining and communicating VMware’s product vision and strategy, and an active advisor for VMware's product roadmap and portfolio. Responsibilities revolved around connecting VMware's R&D team with customers, partners and the field. Serve as a partner and trusted adviser to VMware's customers primarily in the US. Rawlinson specialize on cloud enterprise architectures, software-defined storage, Hyper-converged Infrastructures and business continuity / disaster recovery solutions with focus on Virtual SAN, vSphere Virtual Volumes, as well as storage solutions and technologies for OpenStack and Cloud-Native Applications. Rawlinson is one of the few VMware Certified Design Experts (VCDX#86) and main author of the blog punchingclouds.com.

7 thoughts on “vCloud Suite – vSphere Storage Appliance (VSA) 5.1 Considerations for Successful Brownfield Deployments – Part II

  1. Pingback: VMTN Blog: Technical Marketing Update 2012 – Week 48 – #tmupdate | Virtualization

  2. jeff thompson jr

    Very insightful, thank you for taking the time to put this together. Question: with regards to the VSA addressing overall, what would be ideal, particularly with 4-6 NICs in each host? I presume VLANs are a given. And, specifically the VSAC IP; should it be on the same subnet as the Back End or as the Front End/Management? I’m considering testing this out and simply creating a DHCP scope especially for the VSA so any added expertise you can lend would be greatly appreciated. In any event, thanks again for the blog.

  3. kamlesh

    hi, i do have a query regarding management ip of vsa, where can we see this ip, inside vsa itself or on the frontend switch created by vsa. and is this management ip is different than one which is currently being used by the esxi host for its management.

  4. Demetrius

    In a single or specific peril policy may need to be aware of cover ffor iphone 5 that.
    Remember, insurance iss one of the main reasons behind why such
    insurance is complex and complicated. Whether you believe losing your
    home is the most important thing iss for you to get out of
    the phone book andd then go with what they offter you.

  5. visit

    Hi there would you mind stating which blog platform you’re using?
    I’m planning to start my own blog in the near future but I’m having a tough time selecting
    between BlogEngine/Wordpress/B2evolution and Drupal.
    The reason I ask is because your design seems different then most
    blogs and I’m looking for something completely unique.
    P.S Apologies for being off-topic but I had to ask!

  6. things to sell to make money

    I don’t know whether it’s just me or if everybody else encountering problems with your site.
    It seems like some of the written text within your posts are running
    off the screen. Can somebody else please provide feedback and
    let me know if this is happening to them too?
    This may be a issue with my web browser because I’ve had
    this happen previously. Thank you


Leave a Reply

Your email address will not be published. Required fields are marked *