Part 3 – Configuring Site Recovery Manager (SRM) With HP StoreVirtual VSA

This is where things start to get exciting! We are going to replicate Volumes between Production and DR and then check to ensure that SRM can see the replicated Volumes.

Replication can occur on two different levels, ‘synchronously’ and ‘asynchronously’ naturally it is only used for write’s and not read’s, so what’s the difference?

Synchronous written blocks are sent to the replication SAN, until this is committed by the replication SAN and confirmation received by the replication SAN, no further block’s are allowed to be written by either SAN.  This means that you would have potentially one block of data loss in the event of a SAN failure. This type of replication should only be used in low latency environments, and is the basis for network RAID on the HP StoreVirtual VSA. As a general rule of thumb the latency normal needs to be less than <2ms to achieve this.

Asynchronous written blocks are sent to the replication SAN and no confirmation is required.  The originating SAN just keeps sending more and more blocks on a predefined schedule e.g. 30 minutes.  If you have a SAN failure than your potential data loss is up to last block that the replication SAN had chance to commit.  This is the most commonly used replication type and is supported with the HP StoreVirtual VSA and SRM.

Replicating Volumes

In my lab, I have created two volumes at the Production site called PR_SATA_TEST01 and PR_SATA_TEST02 these are thinly provisioned and contain the VMDK files for VMF-TEST01 AND VMF-TEST02 respectively.

Before we start replicating the volumes, we need to check that we have only assigned the ESXi Hosts at the Production site to the volume.  Look under Assigned Servers to make doubly sure.

Why’s this important Craig, I hear you ask.  Well SRM is responsible for failing over the replicated volume and also presenting it too the ESXi Hosts in the DR site.  If we assign ESXi Hosts to the volume at both sites, we are manually interfering with the SRM process and we also potentially can expose the replicated volume to read/write conditions.

We want to Right Click the Volume we want to replicate, in this case it’s PR_SATA_TEST01 and select ‘New Schedule to Remote Snapshot a Volume’

We need to give the schedule a name, mines going to be PR_SATA_TEST01_RS with a description Replicated Volume.  We are going to replicate every 30 minutes which is the fastest period supported by SAN iQ 9.5.  We are going to retain only 1 snapshot at the Primary site.

For the Remote Snapshot Setup, we are going to use SSDMG01 which is the Management Group at the DR site, and we are giong to retain only 1 copy of the snapshot in DR

TOP TIP: Do NOT tick Include Primary Volumes, if you do then fail back will be a manual process.

We are going to create a New Remote Volume at the DR site.  To do this click on New Remote Volume and select Add a Volume to an Existing Cluster

Double check that your Cluster is at the DR site and click Next

Give the Volume a name, is this case we are rolling with DR_SATA_TEST01 and the description is Replication Volume

Click Finish and Close. We should now be back to the Schedule to Remote Snapshot a Volume screen, but OK is greyed out.  That’s because we haven’t chosen a time for replication to start.

To do this click Edit

Then either select a date/time you want it to start or click OK for it to start immediately.  It has been known that I’m pretty impatient, so I’m going to click OK to start now!

Excellent news, we now have the OK button available to Click, so let’s do that.

You should now see a DR_SATA_TEST01 appear in your DR Cluster and little icons showing the Volume is being replicated to the DR site.

You may have noticed that original Volume PR_SATA_TEST01_RS has (1) at the end and also the replication is happening between PR_SATA_TEST01_TS_Pri.1 and PR_SATA_TEST01_RS_Rmt.1

Let’s take a moment, to explore this as it’s quite an important concept.  Essentially the original Volume PR_SATA_TEST01 has had snapshot taken of it.  This has been renamed with Pri.1 at the end which stands for Primary Volume Snapshot 1.  At the DR site we have an extension Rmt.1 this means Remote Site Snapshot 1.  Make sense?

If we click PR_SATA_TEST01_RS_Pri.1 and select Remote Snapshots we can see the time it’s taken to replicate the volume and the transfer rate as well.

Side note, did you know that Under Remote Snapshot Tasks (at the bottom of the screen) we can even set the bandwidth to be used, pretty cool eh?

Back on track, we now need to do the same for PR_SATA_TEST02

Cool, that’s the replication now all set up, let’s jump back into SRM and check out the Array Managers

Array Managers

Back in SRM, click on Array Managers and then onto Production – StoreVirtual and finally click on Array Pairs and you see, an awesome amount of nothing.  Err Craig what’s going on, I thought I was meant to see Volumes being replicated?

Never fear, hit the Refresh button and click Yes to the Discover Array Pairs operation

Now we should see the Remote Array which is in this case is SSDMG01.  Click Enable

You might have noticed that we you clicked on Enable, it kicked off a load of tasks.  Essentially, SRM is discovering replicated volumes.   Let’s click on Devices and we should now see PR_SATA_TEST01 and PR_SATA_TEST02 being replicated.

Boom, we are cooking on gas now!

TOP TIP: You need to refresh Array Manager devices manually every time you introduce a replicated Volume

Protection Groups

Protection Groups are based on Volumes being replicated.  SRM will automatically look into the Volume and establish which virtual machines are being replicated.  The way I think about it is that all a Protection Group really is, is a replicated Volume.

So we can configure two Protection Groups as we have two replicated Volumes, that should hopefully make sense.

Click on Protection Groups from the left hand menu and then on Create Protection Group

Choose your Protected site, in this case Production (Local) and click Next

Select the Datastore Group which in this case is PR_SATA_TEST01 and you will notice that VMF-TEST01 has automatically been added as a protected VM.

Give the Protection Group a name and description.  Using my creativity I have opted for PG_SATA_TEST01

Click Next and then finally finish.

As always, we now need to repeat the process for PR_SATA_TEST02.  Once done, you will have two Protection Groups like this.

How do we know that what we have done is rock solid? Well if we go onto VMF-ADMIN02 which is our vCenter in DR, we should see VMF-TEST01 and VMF-TEST02 protected by superman, err I mean SRM.

That’s it for this post, in the next one, we are going to get involved with some Recovery Plans!

Part 2 – Configuring Site Recovery Manager (SRM) With HP StoreVirtual VSA

OK, so I feel like I short changed you a bit on my last blog post Part 1 – Configuring Site Recovery Manager (SRM) With HP StoreVirtual VSA as I did’t mention what the heck the Storage Replication Adapter does.

Think of the Storage Replication Adapter as the ‘link’ between your storage vendor’s hardware and SRM.  Essentially it allows SRM to peer down into the murky depths of your SAN and issue commands which would otherwise need to be done by the administrator.  I think an example is in order, the best one I can think of is when we use SRM to do a test failover (something which we will do later).  SRM uses the SRA to allow you to replicate recent changes to the DR site, then it takes a snapshot of the read only replicated volume, changes it to read/write.  How cool’s that we just ‘click the button test’.

Right now that’s covered off, let’s jump into vCenter.  Launch vCenter and you will see, err nothing different.  Why’s that? well we need to install the plug in for VMware vCenter Site Recovery Manager Extension.

Click Plug-Ins from the top menu bar in vCenter and then Manage Plug Ins

Then click on Download and Install under Available Plug-ins

Most likely you will get a Security Warning in relation to your certificates and underlying PKI unless you have a trusted SSL.  In my case I don’t so I will tick the box and ignore

As Windows also likes to give us warnings we have another one in relation to running the installation, click Run.  Then we get to choose the language (it would be nice to get an English (United Kingdom) for us UK folks) anyway, hit OK.

Click, Next, Next and hit Install, and you should end up with a Finish button.

If all has gone to plan, you should see VMware vCenter Site Recovery Manager Extension with an ‘Enabled’ status

I strongly suggest you do the same at the DR site so you keep everything linear.

Next step is configuring the key components of SRM.

SRM Site Connection

Finally we can click some stuff in vCenter and play with SRM.  Click Home and you will see a new Icon under Solutions and Appliances ‘Site Recovery’  I don’t know why but it reminds me of a super hero logo, must be the lightening bolt.

Launch Site Recovery and we are at the landing page, this is where you will spend alot of time.

You will notice that we can only see one site being Production (Local) as we have yet to configure the connection between both vCenters and SRM.

To do this, select Configure Connection from the ‘Commands’ menu on the right hand side

Then enter the address and port of the remote vCenter Server, in this case VMF-ADMIN02 and hit Next

We get another question about certificates, this time we need to validate the vCenter Server Certificate at our DR site, Click OK

We now need to enter the credentials of a user who has rights to access VMF-ADMIN02

Amazing, we have another certificate warning, click OK again.  Hopefully, if all goes well, you should see all green ticks and then hit Finish.

Time to authenticate into VMF-ADMIN02, oh by the way, get used to entering your credentials a lot!

Click OK, and ignore the next security warning (I swear VMware is now trying to wind us up).  Voila we should now see both site Production (Local) and DR.

SRM Mappings

You have probably started to click around on the tabs at the top called Resource Mappings, Folder Mappings and Network Mappings.  These are logical links between our Production and DR sites, which state if you we use the Port Group LAN in Production when we failover to DR, use Port Group DR LAN in DR.  That make sense?

Let’s configure it, I’m sure the penny will drop, if it hasn’t already.

Resource Mappings

The first tab is Resource Mappings, we are going to configure a mapping between Cluster01 at Production and Cluster02 at DR.  To do this we click Cluster 01 and select Configure Mapping.

Expand, Datacenter02 and then select Cluster02 and hit OK

We now have a mapping (logical link) between Cluster01 and Cluster02. Boom!

You can also map Resource Pools between locations, I haven’t created any in this example.  One thing to note is that SRM will not create Resource Pool’s in your DR location, you will need to configure and maintain these on a manual basis.

TOP TIP: Don’t forget to do your reverse mappings, DR to Production for failback

Folder Mappings

Exactly the same principal as Resource Mappings, these create a logical link between our Production and DR sites Folders.  I don’t have any folders below, instead I have linked the Datacenter01 and Datacenter02.

Network Mapping

This is where things start to get interesting.  The network considerations in my opinion are the greatest consideration in your SRM design. Depending on your inter site link, this will have massive implications on what you can or can’t achieve. Let’s discuss these a little further detail below.

Point To Point Link

Let’s say that you have two sites which are connected by Point to Point 100 Mb/s inter site link.  You don’t meet the requirements to use a vSphere Metro Storage Cluster, however why would you want to change all of your virtual servers IP address’s in DR? I certainly wouldn’t want to, the risk of third party applications not working as they have been programmed with a static IP.

In this scenario I would recommend getting your network team to stretch VLAN’s between sites and when you failover to use the same Subnet, VLAN and Port Groups.

MPLS/Site to Site VPN

This is the most common scenario and you really have two choices.  Either RE IP or not to RE IP.  What do you mean Craig, haven’t I got to RE IP as we are on a different site? Well the answer to that is no.

What you can do is get the network team to create the same VLAN at DR as you have in Production, but the key is ensure that the VLAN is shut down! When you failover use the same Subnet, VLAN and Port Groups and then perform a ‘no shut’ on the VLAN and it will work.

TOP TIP: Ensure that you shut down the inter site link port

We are going to make things complicated for ourselves as we are going to RE IP, so that you can see how that works.

Anyway, back on topic when we failover to our DR site, I want my VM’s in DR to be connected to specific Port Groups.  These will be:

  • LAN > DRLAN
  • Backup > DRBackup

We don’t need to worry about our iSCSI connections as SRM combined with the SRA will work that out for us.

If you remember on the first blog post I showed my subnet’s but, as a quick reminder.

  • LAN 192.168.37.0/24 VLAN 1 will become DRLAN 192.168.38.0/24 VLAN 51
  • Backup 10.37.30.0/24 VLAN 30 will become DRVLAN 10.37.31.0/24 VLAN 31

We follow exactly the same procedure for our Network Mappings as we did for the Resource and Folder Mappings, so I want go over old ground.  You should end up with something like this.

Placeholder Datastores

What’s this thing called a Placeholder Datastore? What does it do? Well first of all the datastore only needs to be small, 10GB should be fine for all but the largest environment   Essentially they contain all of the Virtual Machine configuration files.  We are going to RE IP when we perform test failovers, if we changed the IP address of the Production VM in this scenario it would end in dramas.

I have created two Volumes as follows:

  • SATAPLACE01 which will be the Datastore for our Production Site
  • SSDPLACE01 which will be the Datastore for our DR Site

If you need a hand creating a Volume using HP StoreVirtual VSA, refer to my previous blog series How To Install & Configure HP StoreVirtual VSA on vSpehre 5.1

From these two volumes,I then created two Datastores one at Production called SATAPLACE01 and one at DR called SSDPLACE01.

Back to SRM, let’s click on the Placeholder Datastores Tab and then on Configure Placeholder Datastore

Select SSDPLACE01 (yep SRM uses the opposite sites Datastore to hold VM configuration files, makes sense as when your Production site goes down, SRM knows what VM configuration is needed).

Once done, it should look like this.

Then all we need to do is repeat the process at the DR site.

We are cooking on gas! Time to move onto Array Managers.

Array Managers

Array Manager, what’s that all about? Well it’s exactly what it says it is, SRM uses the Array Manager to guess what, manager the array.

If you remember we installed the HP P4000 Replication Adapter in Part 1 – Configuring Site Recovery Manager (SRM) With HP StoreVirtual VSA so the Array Manager section is where SRM delves into our SAN and discovers which Volumes are being replicated and based around this sees what Volumes are being replicated.

With this in mind, we need to configure SRM to let it know where to find the HP StoreVirtual VSA.

Select Array Managers from the left hand side menu, then ensure you are on Production (Local) and then select Add Array Manager

Give the Array Manager a name, I’m going to call mine ‘Production – StoreVirtual’ and Click next

Now we need to enter the IP Address of the HP StoreVirtual VSA and a username and password with credentials to log into the SAN.

TOP TIP: Enter in the VIP Address of the HP StoreVirtual VSA

Click Next and then hopefully you will see a ‘green success’ tick

Click Finish and repeat the process for the DR site.

Once, done you should see you SAN’s on the left hand side

You will notice that under Array Pairs we don’t have anything listed, why’s that? Well this is the area where SRM shows us the replicated Volumes, and as we don’t have any, nothing appears.

Watch out for Part 3, when we will be replicating Volumes between our Production and DR sites.

P4000: An Error Occurred While Reading The Upgrade Configuration File

With any device, it is important to keep up to date with the latest firmware the vendor can offer.

I always check the manufactures websites on a monthly basis to see if anything is new,  with this in mind, I was trying to update my P4000 StoreVirtual VSA today and I kept getting the following error message:

‘An error occurred while reading the upgrade configuration file.  If the file was from a web connection, click Try Download Again, otherwise recreate your media image’.

A quick check in Help > Preferences > Upgrades I saw that the Download Directory location didn’t look quite right.

So I entered a at the end of the Download Directory location

Clicked on OK and started the download again, voila this time it worked!

Part 3 – Automating HP StoreVirtual VSA Failover

In part two we installed and configured HP StoreVirtual VSA on vSphere 5.1 in this blog post we are going to look at automating failover.

I think a quick recap is in order.  If you remember we received a warning when adding SATAVSA01 and SATAVSA02 to the Management Group SATAMG01.  Which was:

‘to continue without installing a FOM, select the checkbox below acknowledging that a FOM is required to provide the highest level of data availability for a 2 storage system management group configuration. Then click next’.

This error message is about quorum, a term that I’m sure alot of you are familiar with when working with Windows clusters.  Each VSA run’s whats known as a ‘manager’ which is really a vote.  When we have two VSA’s we have two votes, which is a tie.  Let’s say that one VSA has an issue and goes down, how does the the remaining VSA know that? Well it doesn’t.  It could be that both VSA’s are up and they have lost’s the network between them.  This then result’s in split brain scenario.

This is where the Failover Manager comes into play.  So what exactly is a Failover Manager? Well it’s specialized version of the SAN/iQ software which runs under ESXi, VMware Player or the elephant in the room (Hyper V).  It’s purpose in life is to be a ‘manager’ and maintain quorum by introducing a third vote ensuring access to volumes in the event of a StoreVirtual VSA failure.  The Failover Manager is downloaded as an OVF and the good news is we already have a copy which we have extracted.

A few things to note about the Failover Manager.

  • Do not install the Failover Manager on a StoreVirtual VSA you want to protect,as if you have a failure the Failover Manager will loose connection.
  • Ideally it should be installed at a third physical site.
  • Bandwidth requirements to the Failover Manager should be 100 Mb/s
  • Round trip time to the Failover Manager should be no more than 50ms

In this environment we will be installing the Failover Manager on the local storage of ESXi02 and placing it into a third logical subnet.  I think a diagram and a reminder of the subnets are in order.

Right then, let’s crack on shall we.

Installing Failover Manager

We are going to deploy SATAFOM onto ESXi02 local hard drive which is called ESXi02HDD (I should get an award for my naming conventions).

The Failover Manager or FOM from now on, is an OVF so we need to deploy it from vSphere Client.  To do this click File > Deploy OVF Template.

Browse to the location of your extracted HP StoreVirtual VSA files ending in FOM_OVF_9.5.00.1215FOM.ovf

Click Next on the OVF Template Details screen and Accept the EULA followed by Next.  Give the OVF a Name in this case SATAFOM and click Next.  When you get to the storage section you need to select the local storage on a ESXi Host which is NOT running your StoreVirtual VSA.  In this case it is ESXi02HDD

Click next and select your Network Mapping and click Finish.

TOP TIP, don’t worry if you cannot select the correct network mapping during deployment. Edit the VM settings and change it manually before powering it on.

If all is going well you should see a ‘Deploying SATAFOM′ pop up box.

Whilst the FOM is deploying let’s talk networking for a minute.

On ESXi02, I have a subnet called FOM which is on VLAN 40.  We are going to pop the vNIC;s of SATAFOM into this.  The HP v1910 24G is the layer three default gateway between all the subnets and is configured with VLAN Access Lists to allow the traffic to pass (I will do a VLAN Access List blog in the future!)

Awesome let’s power the badboy on.

We need to use use the same procedure we used to set the IP address’s on the FOM as we did on the VSA.  Hopefully you should be cool with this, but if you need a helping hand refer back to How To Install & Configure HP StoreVirtual VSA On vSphere 5.1

The IP address’s I’m using are:

  • eth0 – 10.37.40.1
  • eth1 – 10.37.40.2

Failover Manager Configfuration

Time to fire up the HP Centralized Management Console (CMC) and add the IP Address into  Find Systems.

Log into view SATAFOM and it should appear as follows.

Let’s Rich Click SATAFOM and ‘Add to an Existing Management Group’ SATAMG01

Crap, Craig that didn’t work, I got a popup about a Virtual Manager. What’s that all about?

Nows a good time as any to talk about two other ways to failover the StoreVirtual VSA.

Virtual Manager this is automatically added to a Management Group that contains an even number of StoreVirtual VSA’s.  If in the event you have a VSA failure you can start the Virtual Manager manually on the VSA which is working.  Does it work? Yes like a treat but you will have downtime until the Virtual Manager is started and you nerd to also stop it manually when the failed VSA is returned to action.  Would I use it? If you know your networking ‘onions’ you should be able configure the FOM in a third logical site to avoid this scenario.

Primary Site in a two manager configuration you can designate one manager (StoreVirtual VSA) as the Primary Site.  So if the secondary VSA goes offline you maintain quorum.  The question is why would you do this? Honestly I don’t know, because unless you have some proper ninja skills, how do you know which VSA is going to fail? Also you need to manually recover quorum, which isn’t for the feint heated.  My recommendation, simples, avoid.

OK back on topic.  We need to remove the Virtual Manager from SATAMG01, which is straight forward.  Right Click > Delete Virtual Manager.

Let’s try adding the SATAFOM back into Management Group SATAMG01.  Voila it works!  You might get a registration is required notice, we can ignore that as I’m assuming you have licensed your StoreVirtual VSA.

(I know I have some emails, they are to do with feature registration and Email settings)

Let’s Try & Break It!

Throughout this configuration we have used the following logic:

  • SATAHDD01 runs SATAVSA01
  • SATAHDD02 runs SATAVSA01
  • SATAVSA01 and SATAVSA02 are in Management Group SATAMG01
  • SATAVSA01 and SATAVSA02 have a volumes called SATAVOL01 and SATAVOL02 in Network RAID 10

In my lab I have a VM called VMF-DC01 which you guessed it is my Domain Controller, it resides on SATAVOL02.

Power Off SATAVSA01

We are going to power off SATAVSA01 which will mimic it completely failing, no shutdown guest for us!  Fingers crossed we should still maintain access to VMF-DC01.

Crap we lost connection for about 10 seconds to VMF-DC01 and then it returned whys that Craig you ask?

Well if you remember all the connections go to a Virtual IP Address in this case 10.37.10.1 This is just mask as even though the connections hit the VIP, they are directed to one of the StoreVirtual VSA, in this case SATAVSA01.

So when we powered off SATAVSA01 all the iSCSI connections had to be ceased and then represented back via the VIP to SATAVSA02.

Power Off SATAVSA02

To prove this, let’s power on SATAVSA01 and wait for quorum to be recovered.  OK let’s power off SATAVSA02 this time and see what happens.

I was browsing through folders and received a momentary pause of about one second which to be fair on a home lab environment is pretty fantastic.

So what have we learned? We can have Network RAID  1 with Hardware RAID 0 and make our infrastructure fully resilient.  To sum up, I refer back to my opening statement which was the HP StoreVirtual VSA is sheer awesomeness!

Part 2 – How To Install & Configure HP StoreVirtual VSA On vSphere 5.1

Great news, it’s time to fire the HP StoreVirtual VSA’s up!  Excellent, once they have booted, we need to login and configure the IP address of each SAN.

To do this go onto the console screen and type start and press enter

Press enter to login

TOP TIP, to navigate around use tab not the arrow keys

Tab down to Network TCP/IP Settings and press enter

Tab to eth0 and press enter

Type in your hostname, in my case it’s SATAVSA01.vmfocus.local then your IP information

 Once done, go over to OK and then log out.

Rinse and repeat for eth1, obviously giving it a different IP Address!

Then continue for anymore HP StoreVirtual VSA’s you have in your environment.

In my lab, I have four in total, which are:

  • SATAVSA01
  • SATAVSA02
  • SSDVSA01
  • SSDVSA02

In fact, let’s show you a picture along with my IP address schema.

Now you are probably thinking that’s great Craig, but I’m not seeing how I do my SAN configuration? Well for that we need to use the HP P4000 Centralized Management Console.

HP P4000 Centralized Management Console

The HP P4000 Centralized Management Console or CMC as it will now be known, is where all the magic happens! OK well not magic, it’s where we configure all the settings for the HP StoreVirtual VSA.

In the previous blog post Part 1 – How To Install & Configure HP StoreVirtual VSA On vSphere 5.1 we downloaded the HP StoreVirtual VSA software.  In the extracted package we also have the CMC which we need to install to be able to manage the VSA’s.

Jump onto the laptop/server you want to install the CMC onto and navigate to the folder which contains CMC_InstallerCMC_9.5.00.1215_Installer and run this.

I tend to install the CMC onto the server running vCenter, just makes life easier having everything in one place.

It takes a short while to initialize, but we should see this screen soon.

Hit OK, then follow the onscreen prompts, you know the usual next, accept EULA next, OK.

Awesome, so hopefully, you should see the CMC installing.

Launch the CMC and voila we have a screen full of err nothing!

It actually makes sense, as we need to tell the CMC to find the VSA’s we installed via there IP address’s. To do this, click Add and enter your IP Address.  Mine are:

  • 10.37.10.11
  • 10.37.10.13
  • 10.37.10.15
  • 10.37.10.17

If all goes well, you should see your VSA’s being populated.

Click on Add, and hold on a minute, where have they gone? Don’t worry you can see them under Available Systems on the left hand side.

Let’s crack on and start configuring.  Select the Getting Start from the left hand panel and choose 2. Management Groups, Clusters and Volumes Wizard:

Hit next, and we want to create a New Management Group. But what is a ‘management group’ well it’s a logical grouping of VSA’s which are clustered to provide scalability and resilience.  Let’s say we had one SAN with RAID 10 which is a common deployment.  SAN’s are built for resilience e.g. dual PSU’s, dual disk controllers, multiple NIC’s per controller.  If you loose a disk controller, then even though the SAN continues to work you get a massive performance hit as the SAN will go ‘aha’ I don’t have a redundant disk controller and therefore I will turn caching off and every write will be written directly to disk.

If we have  two VSA’s or P4000 within a Management Group that are Clustered running Network RAID 10 we can avoid this situation.  Pretty neat eh?

The first thing we want to do is create a new Management Group and click Next.

Then give the Management Group a name, for me, it’s going to be SATAMG01 as I’m going to have two Management Groups, one for SATA and one for SSD.  Then select the VSA’s which will held by the Management Group.  I have chosen SATAVSA01 and SATAVSA02.  We now get an additional box appear with a warning

‘to continue without installing a FOM, select the checkbox below acknowledging that a FOM is required to provide the highest level of data availability for a 2 storage system management group configuration. Then click next’.

Crikey that’s a bit of warning, what does it mean? Well well essentially it’s about quorum, a term that I’m sure alot of you are familiar with when working with Windows clusters.  Each VSA run’s whats known as a ‘manager’ which is really a vote.  When we have two VSA’s we have two votes, which is a tie.  Let’s say that one VSA has an issue and goes down, how does the the remaining VSA know that? Well it doesn’t, it could be that both VSA’s are up and they have lost’s the network between them.  This then result’s in split brain scenario.  The good news is if this occurs then both VSA’s go into a ‘holding state’ with no LUN access until either the original VSA comes back online or someone from IT performs manual intervention.

Don’t worry we are going to introduce a Failover Manager in a third logical site, I will go over the pre requisites for this in an upcoming blog post.

On the next page we need to enter an ‘Administrative User’ which will propagate down to the VSA’s so that if we try and access them, these are the credentials we need to supply.  Next pop in the details of an NTP server or manually set the time.  My recommendation is always to go for an NTP server preferably one of your DC’s so that your never more than 15 minutes out of sync which can cause dramas!

Onto DNS information now, pop in your DNS Domain Name, DNS Suffix and DNS Server

Onto Email Server settings now, enter in your email Server IP, Sender Address and Recipient Address

We now need to ‘Create a Cluster’ which is two or more VSA’s working in unison providing a highly available and resilient storage infrastructure.  In this case we are going to select Standard Cluster and click next.

Give the Cluster a name, I’m going to roll with SATACL01 and click Next.

This is where things start to get interesting, we now need to ‘Assign a Virtual IP’ to the cluster SATACL01. What does this do? Well all communication for the VSA’s goes via the Virtual IP Address allowing every block of information to be written to both VSA’s simultaneously.  How cool?

Click Add and then Next.

We are now in a position to Create a Volume.  Enter the name,  in my case SATAVOL01 and choose a Data Protection Level.  The choices are Network RAID 0, if we use this then we have no protection, so best to select Network RAID-10 (2-Way-Mirror) and enter your Reported Size.

I have always thought that the Reported Size is quite strange, as why would you want to reported size which is greater than your physical space available? Essentially it’s a poor relation to thin provisioning so the ‘storage team’ can say hey ‘VMware team’ look we have created you a 10TB Volume when in fact they only have 5TB of actual space.

Select either Full or Thin Provisioning and click Finish.  Time to make a cup of tea as this is going to take a while.  Once done you should end up with a screen like this.

Note, you will get a warning about licensing, this is expected.  We are ‘cooking on gas’.  Now it’s time to present the volumes to VMware.

vSphere iSCSI Configuration

For the iSCSI configuration we are going to head into VMware, to grab the initiator FQDN’s.  For completeness, I’m going to cover this as well!

Head into vCenter then onto your ESXi Host, select the Configuration Tab, then select Storage Adapters followed by Add and choose ‘Add Software iSCSI Adapter’

Now that’s done we need to bind out VMKernel Port Group to iSCSI.  To do this click your new iSCSI Software Adapter and click Properties.  This essentially says ‘hey I’m going to use this special VMKernel port for iSCSI traffic’.

Select the Network Configuration tab and click Add

Then select your iSCSI Port Group and click OK

Hopefully, once done it looks a bit like this.

Next we need to enter in the IP Address’s of the VSA Virtual IP Address we want to connect to under the Dynamic Discovery Tab.  Again it should resemble something like this.

Last bit of work before we head back over to the CMC, is that we need to grab the vSphere iSCSI Initiator FQDN.  Good news this is the page we find ourselves at.  So get make a note of what yours are.

Mine are:

  • ESXi02 – iqn.1998-01.com.vmware:ESXi02-0f9ca9cc
  • ESXi03 – iqn.1998-01.com.vmware:ESXi03-36a2ee1c

CMC iSCSI Configuration


We are on the final hurdle! Expand your Management Group then select Servers, click Tasks > New Server

Complete the details and paste in the Initiator Node Name.  Rinse and repeat for the servers you want to present your volumes too.

TOP TIP, I recommend you set up a Server Cluster, this is feature of most SAN’s.  It enables you to group common ‘hosts’ together so that rather than having to present a volume to each server/host individually, you present it to the cluster saving you the administrator time (which I’m all for, as we can fit in more cups of tea).

Back to Tasks then Select New Server Cluster and enter the Cluster Name and Description. Once done it should resemble this.  I know great imagination Craig ‘ESXiCL01’

Last of all we need to ‘assign’ the cluster ESXiCL)1 to access the Volumes.  To do this go to Volumes and Snapshots right click the volume you want to present to your server and click ‘Assign and Unassign Server’.  Place a tick in Assigned.

A quick jump over to vCenter and a quick ‘Rescan All’ of our Storage Adapters should reveal.

Boom, there we have it! In the next blog post we can crack on and install the Failover Manager and perform some testing!