Home > Blogs > VMware vSphere Blog > Category Archives: Storage

Category Archives: Storage

VMware Virtual SAN: File Services with NexentaConnect

Nextenta+VSAN

NexentaConnect for Virtual SAN is a software-defined storage solution designed specifically to deliver file service on top of Virtual SAN. This solution complements Virtual SAN by delivering a software-based NAS capabilities that add enterprise-class Windows and UNIX-based file services without the need for any additional hardware purchase to augment the virtual machine storage provided by VMware Virtual SAN.

NexentaConnect is designed to deliver high-performance NFS and SMB file services to the full datacenter by leveraging Virtual SAN features and capabilities. The management and configuration of the solution adopts Virtual SAN simplified management approach delivering an agile and efficient operational model. The solution delivers NFSv3, NFSv4, and SMB 2.1 file shares services for hybrid networks, as well as its set of capabilities relate to performance, availability, and storage services such as:

  • Localized server-side read cache
  • Compression and de- duplication

NexentaConnect for Virtual SAN maintains data integrity under high workload, network/disk/host recovery and brings various recovery functions, such as snapshot and remote file replication designed specifically for this solution. All configured and managed through the vCenter console and the vSphere Web Client.

Key integrations into the VMware Virtual SAN environment:
  • Easily install and provisions file services (NFSv3, NFSv4, SMB) on Virtual SAN within minutes.
  • Complete management through the vSphere Web Client interface.
  • Runs seamlessly on Virtual SAN and is compatible with VMware HA and DRS
  • Security and Domain integration, AD with AAA and Kerberos support
  • Leverage Virtual SAN’s data protection, performance, and availability

NexentaConnect complements Virtual SAN deployment by utilizing local Virtual SAN storage capacity in servers to deliver high-performance NFS and SMB file services to the full datacenter. NexentaConnect orchestrates the deployment and configuration of enterprise-class file services on Virtual SAN in a short period.

The NexentaConnect solution is comprised of the following components:

NexentaConnect vSphere Web Client Plugin – Provides management integration with to the vSphere Web Client and vSphere Client.
NexentaConnect Manager – is a virtual appliance that provides centralized services such as schedule events, monitoring, licensing, database services and orchestration of all the configuration and management functions for the solution.
NexentaConnect Filers – deployed on-demand when the first folder is created.

  • One Filer per Virtual SAN cluster
  • Separate file system (pool of 2TB VMDKs) per every VM Storage Policy
  • Note: 2TB is to fulfill Virtual SAN 5.5 supportability
  • Default 128K block size
  • Elastic – scales on-demand as Virtual SAN scales
  • Thin provisioned or reserved space options offered

NexentaConnect leverages proprietary data services and technologies such as compression to reduce the data on top of Virtual SAN to deliver:

  • LZ4 compression algorithm (lossless, LZ77 family)
  • Real-time and extremely light on CPU
  • Over 500 MB/s on compression (Per core)
  • Over 1.5 GB/s on decompression (Per core)
  • Suppresses some internal headers and zero padding (aka zero-block deduplication)
  • De-duplication is planned for v.2.0, currently available in tech-preview
The NexentaConnect Manager virtual appliances characteristics:
Ubuntu Linux (64 Bit) based appliance
  •  Single vCPU
  •  3 GB of RAM
  •  Single 20 GB Disk
  •  1 Network Adapter

Nexenta IO Engine – are virtual appliances that are deployed as filer on Virtual SAN datastore purpose-built and optimized to run on VMware ESXi hypervisor. The Nexenta IO Engines filers can scalable Up to 30 VMDKs per virtual appliances. Each drive supporting up to 2 Terabytes per VMDK serving virtually unlimited file shares virtual infrastructure

Nexenta IO Engine virtual appliance characteristics:
  • Ubuntu Linux (64 Bit) based appliance
  • 4 vCPU
  • 16 GB of RAM
  • Minimum of 2 Virtual Disks (scalable up to 30)
  • Virtual Disk capacity up to 2 TB per disk
  • 2 Network Adapters
NexentaConnect for Virtual SAN Requirements:
  • VMware vSphere 5.5 or later
  • VMware vCenter Server 5.5 U1 or later (Windows and Linux)
  • ESXi 5.5 U1 or later
  • VMware vSphere Cluster with Virtual SAN enabled
  • VMware vSphere Web Client
  • VMware HA (optional)
  • Directory Services (optional)
  • Microsoft Windows Active Directory 2008 R2 or later
  • VMware vCenter Server 5.5 U1 or later
  • Network Services
  • DNS
  • DHCP

NexentaConnect for VMware Virtual SAN extends Virtual SAN use-cases for scale out datastores and enables administrators to build full-featured hyper-converged pods capable of supporting mixed virtual machines workloads and high performance shared
storage services. 
Primary uses cases, among others, are virtual desktops, pre-production, test and development environments.

Virtual Desktops: Providing a hypervisor-converged solution to include the desktops, as well as user persona data.
Remote and Branch Office (ROBO): Addresses the need for scale-out NAS functionality 
Lab & Development: Avoids acquisition of expensive storage, lowers time to provision.
Disaster Recovery Target for files: Lower-cost DR solution, enabled through a built-in 
snapshot and remote replication capabilities of NexentaConnect.

Overall, the NexentaConnect for Virtual SAN solution should be considered when looking to deliver file services for virtualized infrastructures on top of VMware Virtual SAN. NexentaConnect for Virtual SAN is not a VMware developed or owned solution for more information about NexentaConnect for Virtual SAN visit their product page.

NexentaConnect for Virtual SAN

– Enjoy

For future updates on Virtual SAN (VSAN), vSphere Virtual Volumes (VVOLs) and other Software-defined Storage technologies as well as vSphere + OpenStack be sure to follow me on Twitter: @PunchingClouds

Storage and Availability at Partner Exchange 2015

VMware’s 2015 Partner Exchange is now just about one week away, and it’s shaping up to be a great one!

In storage and availability we’ll have a lot to talk about across the board: Some sessions will offer deeper examinations of our current products, others will give you a great exploration of some of the newer things VMware has to showcase.

I’ve made a list of some of the sessions put on by those of us in the storage and availability product team; it’s a good cross section from product marketing, product managers, and technical marketing people such as myself.  Outside of the engineers who actually write the code, these are the people closest to the products you use, so sign up and hear something new.  There are also sessions from our highly experienced field sales and technical teams — the experts at understanding how these products address customer requirements and explaining their value to our customers.

I’m personally doing a technical session with my colleague Rawlinson on Virtual SAN (STO4275) and looking forward to it quite a bit.

Lastly, don’t be shy to come say hello after the sessions.  We love to hear your thoughts, if we’ve got time between activities…

Continue reading

Storage Blog Recap: Top Blogs from December

In case you missed it, we’ve compiled a list of the top vSphere Storage posts from December for you to digest. Check it out!

VMware Virtual SAN and ScaleIO: Fundamentally Two Different Approaches to Software-Defined Storage

VMware’s Vijay Ramachandran clarifies how VMware Virtual SAN’s unique approach to software-defined storage stands apart from other SDS competitors.

Gartner Predictions: Storage Integration Leading the Way in 2015

Learn why Gartner predicts that 40% of midsize enterprises will replace all data center services and storage with integrated systems by 2018.

Continue reading

Performance Unplugged: Demanding Applications

Welcome to a new video series I’ve titled “Performance Unplugged”

In this video series, I’ll showcase a number of talented performance gurus and cover commonly asked questions and topics. Performance of the Software-Defined Datacenter should no longer be a concern for customers and we’ll explain why. Links to the latest information pertaining to the topic will also be provided.

Continue reading

Discover Software-Defined Storage & VMware Virtual SAN at PEX 2015!

Are you a VMware partner? Come learn more about VMware Virtual SAN — our software-defined storage solution designed for vSphere environments — at VMware Partner Exchange (PEX) 2015.

The sessions, like the rest of PEX 2015, will take place at the Moscone Center in San Francisco, California, February 3 – 5th. Depending on your needs, there will be several important Software-Defined Storage and VMware Virtual SAN sessions you won’t want to miss.

If your organization is concerned about enterprise-level storage and availability, add these Software-Defined Storage and VMware Virtual SAN sessions to your calendar. (Log on and register to view session abstracts, speakers, and locations.)

Tuesday 2/3

  • STO4280: 12:30 PM – 1:30 PM, VMware Software-Defined Storage Overview
  • STO4278: 2:00 PM – 3:00 PM, Virtual Volumes Technical Overview
  • STO4273: 3:30 PM – 4:30 PM, What’s New with VMware Virtual SAN and How to be Successful Selling It
  • STO4289: 5:00 PM – 6:00 PM, Conducting a Successful Proof of Concept for Virtual SAN

Wednesday 2/4

  • STO4295: 11:30 AM – 12:30 PM, SRM & Business Continuity Overview
  • STO4275: 12:45 PM – 1:45 PM, Virtual SAN Technical Walkthrough
  • STO4290: 2:00 PM – 3:00 PM, Delivering SDS to SAN/NAS with Virtual Volumes
  • STO4464: 3:15 PM – 4:15 PM, Virtual SAN Panel: View from the Sales Trenches
  • STO4465: 4:30 PM – 5:30 PM, Performance and Best Practices for Business Critical Applications leveraging Virtual SAN

Thursday 2/5

  • STO4293: 9:00 AM – 10:00 AM, SRM & VR6 Technical Deep Dive
  • STO4276: 10:15 AM – 11:15 AM, Virtual SAN Hardware Guidance & Best Practices
  • STO4279: 11:30 AM – 12:30 PM, Software-Defined Storage: the Key to Agility with Control

Be sure to follow our social channels at @vmwarevsan and Facebook.com/vmwarevsan for the latest updates.

For more information about VMware Virtual SAN, visit http://www.vmware.com/products/virtual-san.

VMware Virtual SAN and ScaleIO : Fundamentally Two different approaches to Software-Defined Storage

There’ s a lot of buzz and excitement around Software-Defined Storage (SDS) and hyper-converged storage solutions.  Particularly around VMware’s recently introduced product: VMware Virtual SAN.

VMware Virtual SAN is seeing tremendous traction in the market since its release. After only two full quarters of availability, we already have many hundreds of customers happily running a variety of applications on Virtual SAN, from VDI to test & development  to production applications and databases.  Virtual SAN customers love the product’s simplicity and integration with the VMware stack.

But along with increased awareness and traction, we are also seeing an increasing level of confusion in the market on the key differences between Virtual SAN and other SDS products.  Particularly, we have been receiving a great deal of questions from our customers and partners about differences between Virtual SAN and EMC ScaleIO. They are asking us about where Virtual SAN should be used, where ScaleIO should be used, and whether there’s any real difference between the two.

This type of confusion is unfortunate because VMware Virtual SAN and ScaleIO follow two fundamentally different approaches to SDS.

  • VMware Virtual SAN is designed specifically around tight integration with vSphere – with the objective of providing super-simple management and very high levels of performance for vSphere VMs.  Virtual SAN is always deployed in a hyper-converged configuration, where storage is converged with the vSphere compute nodes. Virtual SAN is targeted at the generalist IT professional, not just storage experts.
  • ScaleIO has a different design point – to provide highly scalable server-based storage for heterogeneous platforms, including multiple hypervisors and physical servers. ScaleIO has its own installation, configuration and management workflows which are typically driven by expert storage administrators.

The confusion between VMware Virtual SAN and ScaleIO is partially fueled by recent press articles, which claim full integration of ScaleIO into vSphere’s ESX kernel.  This claim is not accurate. There are no plans to port the core ScaleIO product in the ESX kernel or integrate it with the rest of the vSphere stack.

More specifically, ScaleIO consist of two  components: a) a block storage server that is the core of the ScaleIO product and which serves block storage to its clients through the ScaleIO protocol; b) a client which connects to the server and allows VMs and applications to access storage on ScaleIO clusters. This model is very similar to an iSCSI target server serving data to iSCSI initiators. EMC has written an ESX kernel driver that implements a ScaleIO client module. It ‘talks’ the ScaleIO protocol and accesses the ScaleIO server(s). It exposes storage to VMs running in vSphere in a way similar to iSCSI volumes. This ScaleIO driver has been written using  public kernel APIs that are available to any VMware partner who develops kernel drivers in ESX. The ScaleIO server is not being ported in or integrated with vSphere and the ESX kernel. The ScaleIO server runs on Linux servers, either on bare metal or as a virtual appliance.

This architectural model allows ScaleIO to be a great SDS solution for heterogeneous platforms.

In the case of bare metal deployments VM I/O goes through the in-kernel driver and onto the external ScaleIO cluster over an IP network as it is the case with other storage arrays. In the virtual appliance case, a VM I/O operation traverses the ESX storage stack through the virtual appliance.

In contrast, VSAN and all its components are natively integrated with vSphere. The key functional components of VSAN, including its “server” functionality, run in the ESX kernel. This fundamental difference in architecture allows VSAN to be optimized for vSphere VMs in an unparalleled way.  VSAN is also integrated directly with the ESX control plane, vCenter  and vSphere APIs to provide a simple and effective management experience.  Together, these integrations provide important benefits to vSphere customers:

  • Performance and Overhead: The full kernel integration gives VMware Virtual SAN higher levels of performance and efficiency because Virtual SAN can more efficiently utilize the available memory and CPU cycles. Hence, Virtual SAN’s memory footprint and CPU cycles consumed per operation are the lowest in the market. Furthermore, compute and storage operations are executing inside the same layer of software, minimizing communication latencies.  This efficiency translates to  more compelling performance and total-cost-of-ownership  for the end user[V3] . By contrast, no other hyper-converged solution has its “server” logic integrated in the vSphere kernel, limiting the gains and efficiencies that can be achieved by these solutions.
  • Management integration: Virtual SAN is designed to be managed through vCenter, by any administrator who is familiar with vSphere.  The setup, configuration and ongoing management of the product are simple and  fully integrated with vSphere management workflows.  As a result, there are no separate management consoles and solutions. The required storage properties of each VM and virtual disk are expressed in the form of policies.  Effectively, storage becomes a quality of every VM, not a separate function.
  • Programmatic APIs: The functionality of Virtual SAN’s control plane is exposed through new or extensions to existing vSphere APIs. These are stable APIs with s wide range of language bindings that VMware customers have been using for years to automate their operational processes.
  • vSphere Features: In addition, since Virtual SAN is embedded within the hypervisor, all vSphere features such as DRS, vMotion, SVMotion, High Availability, vSphere Replication, and others are seamlessly supported with VSAN.

VMware Virtual SAN’s architectural model allows it to be the best storage solution for hyper-converged vSphere environments and for vSphere VMs. It does not address non-vSphere storage needs today.

So what does it mean in terms of where each solution should be used? In practice things are never black or white as we would like them to be, but at a high level there are some key aspects that we can keep in mind when comparing:

  • Use VMware Virtual SAN if you value deep integration with vSphere, both on the data path and control plane. Virtual SAN is deployed in a hyper-converged model, where storage is converged with compute on the same x86 hosts and storage scales in alignment with vSphere clusters (up to 32 nodes per cluster today, soon to become 64). We believe the Virtual SAN approach delivers highly differentiated, unique advantages for customers of all sizes looking for an SDS solution for vSphere.
  • Use ScaleIO when delivering highly scalable shared storage from a single storage pool to different hypervisors or across multiple vSphere clusters. The primary use case for ScaleIO is serving storage for a heterogeneous environment (i.e when storage is served to a diverse set of hypervisor clients or between virtual and physical environments) or when the storage system needs to scale beyond the size of a vSphere cluster.

The picture below should help clarify what these two products are positioned for:

VSAN                ScaleIO

 

Gartner Predictions: Storage Integration Leading the Way in 2015

Rowing crews move in sync to keep their craft moving at a steady pace – but that synchronous movement would not exist without an investment in the right hardware and the right training. For businesses, that means not only investing in the right rowers, but also in the right tools to enable athletes. And for a long time those tools, namely storage for midmarket organizations, have either been too expensive, too resource heavy or too complex.

It doesn’t have to be that way. Midmarket teams should be able to afford the right equipment without worry so they can focus on more important tasks. That’s why we’re thrilled to discover Gartner Research included VMware Virtual SAN in their recent report, “Predicts 2015: Midmarket CIOs Must Shed IT Debt to Invest in Strategic IT Initiatives.”

The report investigates how CIOs can best invest resources to give IT teams the simplified tools they need while staying on budget. Often, this excludes “best of breed” solutions. Gartner suggests midsize businesses seek out integrated systems that combine server, storage and network components in a package suitable for their needs instead.

For many, Virtual SAN, VMware’s policy-driven storage product design for vSphere environments, is that solution. Its ease of use, performance, scalability and low total cost of ownership helps to avoid significant upfront investments. And, with its VM-level storage policies, Virtual SAN automatically and dynamically matches requirements with underlying storage resources. Meaning less time manually managing storage tasks and more time focusing on important tasks.

According to Gartner’s predictions, roughly 40% of midsize enterprises will replace all data center services and storage with integrated systems by 2018. We certainly would like to see, and be at the forefront, of that transition.

VMware Virtual SAN stands apart from the competition not just because of its ability to deliver simple software defined shared storage, but also because of its integrated partner ecosystem. More than 40 Virtual SAN Ready Nodes can be purchased from our system vendor partners.

We’re thrilled to have been a part of software defined storage in 2014, and we can’t wait to push the envelope further in 2015.

Be sure to subscribe to the Virtual SAN blog or follow our social channels at @vmwarevsan and Facebook.com/vmwarevsan for the latest updates.

For more information about VMware Virtual SAN, visit http://www.vmware.com/products/virtual-san.

VMware’s vSphere Big Data Extensions (BDE) achieves Hortonworks Operations Ready Certification

 

Hortonworks announced on the 17th December 2014 that VMware’s Big Data Extensions tool for Hadoop on virtual machines is now both HDP Certified and Operations Ready. HDP is the Hortonworks Data Platform – an open Hadoop platform that is centered on YARN. The Operations Ready designation is a new certification introduced by Hortonworks to focus attention on those tools that integrate in an approved way with Apache Ambari by making use of the open Ambari management application programming interfaces. The focus of the program is to certify operational tools for managing a Hadoop/HDP cluster. The Operations Ready program also provides assurance to enterprises adopting Hadoop that the tools they select to run and interact with Hadoop have been tested and validated to work correctly. At VMware we are excited to get this additional level of certification for VMware’s BDE and we look forward to continued engineering collaboration with Hortonworks.

Here is the description of the new Operations Ready program from Hortonworks:

http://hortonworks.com/partners/certified-technology-program/ops-ready/

You probably by now have also seen the recent VMware Big Data Extensions 2.1 announcements. Here is a quick summary of those new features in 2.1:

http://blogs.vmware.com/vsphere/2014/10/whats-new-vsphere-big-data-extensions-version-2-1.html

BDE 2.1 was announced as being Generally Available in October 2014. One of the central new features in BDE 2.1 is better integration with the de-facto Hadoop management tools from the distro vendors. Chief among those tools is Ambari. This integration with Ambari was the result of a request made to us directly by the VMware BDE user community.

BDE 2.1, with the new application manager construct, can now use the Ambari APIs under the covers to provision the HDP software into the virtual machines that it has created through cloning its template virtual machine. This method of deploying everything through BDE ensures that the resulting new Hadoop cluster is entirely compatible with Ambari. That is important because many of our users would like to use Ambari and VMware vCenter together from the point at which a cluster is provisioned onwards.

  • Ambari is the management tool of choice among HDP users in order to gain insight into what is going on at runtime at the Hadoop level (e.g. checking the status of HDFS, YARN, MapReduce and other services) and to make service changes there.
  • VMware vCenter is the virtualization infrastructure management tool that is in use at tens of thousands of VMware’s customers to view system behavior and performance at the virtual infrastructure level (virtual machines, physical machines, consumed resources and performance data). vCenter with the BDE plug-in is in popular use for deploying user Hadoop clusters today at many enterprises.

The BDE plug-in uses the vCenter APIs as well as the Ambari Blueprint APIs. Combining the two tools together to collaborate on the Hadoop provisioning details simplifies the management of your virtualized Hadoop cluster significantly. Both the Hadoop application architect and the virtualization manager can converse about the components of the HDP cluster and their effect on hardware consumption.

Hortonworks’ new Operations Ready program is one of a set of certifications that are currently available from the company. Other certifications available are the YARN Ready, Security Ready and Governance Ready programs. You can read more about the new programs here:  http://hortonworks.com/blog/accelerating-adoption-enterprise-hadoop

You can find the full BDE Administrator’s  and User’s  Guide and the BDE Command Line Interface Guide, as well as the Release Notes at: https://www.vmware.com/support/pubs/vsphere-big-data-extensions-pubs.html

 

Operationalizing VMware Virtual SAN: Automating vCenter Alarm Configuration Using PowerCLI

powercli 5.8 icon

Welcome to the next installment in our Operationalizing VMware Virtual SAN series. In our previous article we detailed “How to configure vCenter alarms for Virtual SAN”. In today’s article we will demonstrate how to automate that configuration workflow leveraging PowerCLI.

(Many thanks to VMware genius Alan Renouf (@alanrenouf) for his contributions to this topic) [Joe Cook: @CloudAnimal]

The PowerCLI code required to automate the configuration of vCenter Alarms for Virtual SAN is considerably straightforward.

1. Connect to vCenter

Connect-VIServer -Server 192.168.100.1 -User Administrator@vsphere.local -Password vmware

2. Define the the Virtual SAN cluster where you would like the rules to be created

$Cluster = "Cluster Site A"

3. Next we create a hash table with the desired VMware ESXi Observeration IDs (VOB IDs) for Virtual SAN and include a description for each VOB ID.

If you are not used to programming, the concept of arrays and hash tables may be a bit confusing. Using variables is generally much easier to understand. One way of understanding variables is to think of them simply as a short amount of text used to represent a larger amount of text in your program or script ($x=”larger amount of text”). Instead of typing “larger amount of text” continually, you can simply type $x and the language interpreter (in our case PowerShell), will substitute the string “larger amount of text” wherever it finds $x in your script. Variables can be used to greatly reduce the amount of code you have to type, make your scripts much easier to read, and have many other uses as well.

If we think of variables as ways to store one value to reference, we can think of arrays as a way to store multiple values to reference. In our example today, we would have to create at least 32 variables to perform the same work that we can with one hash table.

A hash table is a type of array that is also known as a dictionary. It is a collection of name-value pairs (e.g. “name”=”value”) that can be used . Here we have an example of a basic hash table:

$HashTableName = @{
VOB_ID_A="VOB Description";
VOB_ID_B="VOB Description";
VOB_ID_C="VOB Description";
}

In the table below we have a breakdown of the components of the code used to create a hash table:

Syntax Component Description
$HashTableName = Replace “HashTableName” with the text you wish to use to reference this list of key-values pairs.
@{ Indicates the start of the hash table or array
VOB_ID_A=”VOB Description”; Key-Value pair to store within the hash table. VOB_ID_A will be the VOB ID from the VMware ESXi Observation Log (VOBD) (e.g. “esx.audit.vsan.clustering.enabled”). “VOB Description” will be the description of the associated “VOB ID” (e.g. “Virtual SAN clustering service had been enabled”). Make sure to use quotation marks whenever spaces are used and to separate each key-value pair with a semicolon (;).Examine /var/log/vobd.log on your vSphere host to obtain possible VOB IDs. See here for a list of VMware ESXi Observation IDs for Virtual SAN.
} Indicates the end of the hash table or array

Here is an example of a hash table with a single key-value pair representing a single vCenter Alarm for Virtual SAN:

$VSANAlerts = @{
"esx.audit.vsan.clustering.enabled" = "Virtual SAN clustering service had been enabled";
}

Below is the actual hash table that we will use in our example Virtual SAN Alarm Configuration script. It is fully populated with all of the recommended VOB IDs for Virtual SAN along with the description for each. We have labeled this hash table as “$VSANAlerts”. You will see $VSANAlerts referenced further along in the script as we reference the items within our hash table.

$VSANAlerts = @{
 "esx.audit.vsan.clustering.enabled" = "Virtual SAN clustering service had been enabled";
 "esx.clear.vob.vsan.pdl.online" = "Virtual SAN device has come online.";
 "esx.clear.vsan.clustering.enabled" = "Virtual SAN clustering services have now been enabled.";
 "esx.clear.vsan.vsan.network.available" = "Virtual SAN now has at least one active network configuration.";
 "esx.clear.vsan.vsan.vmknic.ready" = "A previously reported vmknic now has a valid IP.";
 "esx.problem.vob.vsan.lsom.componentthreshold" = "Virtual SAN Node: Near node component count limit.";
 "esx.problem.vob.vsan.lsom.diskerror" = "Virtual SAN device is under permanent error.";
 "esx.problem.vob.vsan.lsom.diskgrouplimit" = "Failed to create a new disk group.";
 "esx.problem.vob.vsan.lsom.disklimit" = "Failed to add disk to disk group.";
 "esx.problem.vob.vsan.pdl.offline" = "Virtual SAN device has gone offline.";
 "esx.problem.vsan.clustering.disabled" = "Virtual SAN clustering services have been disabled.";
 "esx.problem.vsan.lsom.congestionthreshold" = "Virtual SAN device Memory/SSD congestion has changed.";
 "esx.problem.vsan.net.not.ready" = "A vmknic added to Virtual SAN network config doesn't have valid IP.";
 "esx.problem.vsan.net.redundancy.lost" = "Virtual SAN doesn't haven any redundancy in its network configuration.";
 "esx.problem.vsan.net.redundancy.reduced" = "Virtual SAN is operating on reduced network redundancy.";
 "esx.problem.vsan.no.network.connectivity" = "Virtual SAN doesn't have any networking configuration for use."
 }

(For more information on working with PowerShell hash tables, see this handy Microsoft TechNet article)

4. Next we use the Get-View cmdlet to query the vCenter Alarm Manager for each VOB ID listed in step 3.

The Get-View cmdlet returns the vSphere inventory objects (VIObject) that correspond to the specified search criteria.

$alarmMgr = Get-View AlarmManager
 $entity = Get-Cluster $Cluster | Get-View
 $VSANAlerts.Keys | Foreach {
 $Name = $VSANAlerts.Get_Item($_)
 $Value = $_

5. Create the vCenter Alarm specification object

 $alarm = New-Object VMware.Vim.AlarmSpec
 $alarm.Name = $Name
 $alarm.Description = $Name
 $alarm.Enabled = $TRUE
 $expression = New-Object VMware.Vim.EventAlarmExpression
 $expression.EventType = Vim.Event.EventEx
 $expression.eventTypeId = $Value
 $expression.objectType = "HostSystem"
 $expression.status = "red"
 $alarm.expression = New-Object VMware.Vim.OrAlarmExpression
 $alarm.expression.expression += $expression
 $alarm.setting = New-Object VMware.Vim.AlarmSetting
 $alarm.setting.reportingFrequency = 0
 $alarm.setting.toleranceRange = 0

6. Create the vCenter Alarm in vCenter

 Write-Host "Creating Alarm on $Cluster for $Name"
 $CreatedAlarm = $alarmMgr.CreateAlarm($entity.MoRef, $alarm)
 }
 Write-Host "All Alarms Added to $Cluster"

As you can see, the steps to create vCenter Alarms for Virtual SAN are actually pretty straightforward. If you have not yet began monitoring your Virtual SAN environment, these steps can accelerate the process quite rapidly and you really do not have to be an expert in PowerCLI to do so.

VMware Hands on Labs

Here is a great tip brought to you by our friends at the VMware Hands on Labs. If you would like an excellent shortcut to getting “hands on” creating vCenter Alarms for Virtual SAN, using PowerCLI cmdlets, try out the lab below:

HOL-SDC-1427 – VMware Software Defined Storage: Module 5: Advanced Software Defined Storage With SPBM and PowerCLI (30 minutes)

 

We have many more articles on there way so share, re-tweet, or whatever your favorite social media method is. You will not want to miss these!

(Thanks to @millardjk for his keen eye)


Resources

 

VMware Storage Survey

spbm2bThe VMware Storage and Availability team is looking for customer and community feedback with regarding some storage technologies and use cases. Please take a few minutes to fill out the brief survey listed in the link below.

Storage Technology & Use case

Thank you for your help and support.

For future updates on Virtual SAN (VSAN), Virtual Volumes (VVols), and other Software-defined Storage technologies as well as vSphere + OpenStack be sure to follow me on Twitter: @PunchingClouds