3PAR & InfoSight

Whilst at HPE Discover I managed to nab some screenshots of the new 3PAR implementation of InfoSight. You can read my post about all the InfoSight announcements.

To get InfoSight up and running with 3PAR you need to be running 3PAR OS 3.3.1, have an active support contract and have the 3PAR communicating back to base. The initial release, available in January will focus on delivering greater insight into the performance of VM’s on the storage.  This is achieved by adding additional functionality to the Service Processor which will allow it to talk to the vCentre in your environment.  Once you have your 3PAR setup with InfoSight you will see two key areas of information, storage information which today will be the same as information being retrieved from StoreFront remote. Secondly you will see the virtualisation layer info being pulled back from vCentre.


Below is the screenshots I managed to gather of InfoSight with 3PAR:

Key host storage performance stats – IOPS, latency and throughput

3PAR InfoSight Storage Performance

The more familiar looking information previously available in Storefront Remote

3PAR Storefront Remote

High level VM overview

3PAR InfoSight VM overview

The following screens allow “noisy neighbour analysis”. They look at various stats to identify which VMs are working your environment the hardest and potentially causing contention in the environment.

Top VMs by latency and IOPs

InfoSight VM IO Contention

Top VMs by CPU usage

Top VM by CPU Useage

Top VMs by data usage

Top VM by data useage

This menu shows all the contention reports available

Seen the 3PAR simulator video setup guide?









3PAR InfoSight

Discover News – InfoSight Comes to 3PAR and gets AI

HPE Discover is due to kick off in Madrid next week and HPE have continued their current tradition of releasing all the big news before the show.

I’ve been lucky enough to attend a few Discovers now and I have noticed some interesting trends in the type of announcements. Previously it was all about physical products, what were the newest models what were the hardware innovations in these products. This year all the key announcements are software based and focus on enhancing user experience.


Ironically for many years whilst storage systems stored lots of data on them, the data analytics for managing the systems was somewhat lacklustre. Data was gathered from these systems and sent back to base but it was a simple affair which alerted you to failed components such as a disk. Nimble Storage saw a unique opportunity in this area and acted upon it by developing their class leading InfoSight analytics platform.

Like other storage systems Nimble sends data home, but where things get different are in the breadth of statistics collected and what happens to them once they are sent back to base. Nimble realised that by taking the data from their entire install base and then using machine learning against this, insights could be developed to predict issues before they even occur. I have two impressive stats to back this up; 86% of issues are being detected and fixed before the customer even knows about it and 54% of issues resolved are outside of storage. This ability to diagnose issues outside of storage closed what Nimble termed the app data gap.

InfoSight adds AI

The first major announcement from HPE Discover is that InfoSight is now able to utilise AI. We discussed previously how Nimble had built a cloud analytics platform from all the data that was being sent home. InfoSight was able to analyse and predict future patterns using machine learning. The introduction of AI allows this to be taken to the next level by enabling more complex issues to be automatically addressed.

Recommendations will go beyond simple problem prevention to include resource optimisations, ensuring you getting the most from your system. Again this is not just for the storage itself but the whole ecosystem for example it may recommend the movement of a VM to a different volume. The name of this new AI functionality “AI recommendation engine” clearly indicates its future direction for further automation.

You can see more about the AI capabilities in the video below:

InfoSight comes to 3PAR

The second piece of InfoSight news is that it is coming to 3PAR. 3PAR has always had a rich amount of telemetry being sent home but up until now it has arguably not been fully utilised. But of course lots of data without the tools to interpret and act upon it is not much use and this is what InfoSight has enabled.

3PAR InfoSight

Like the Nimble system before it InfoSight on 3PAR will not just report on the storage itself but down to the application level. To benefit from InfoSight on 3PAR you need to be running 3PAR OS 3.3.1 have an active support contract and of course have your 3PAR configured to dial home.


The Nimble AI recommendations and 3PAR InfoSight are both free for customers with a active support contract and are expected in January 2018

I’m sure that the HPE engineering team are working at a furious pace to get InfoSight out across to as many products, as quickly as possible. It’s clear to see that improved analytics would not only reduce operational issues but that the introduction of AI driven resource recommendations will drive the move to an automated data centre. It seems obvious that automated resource allocation recommendations would fit in nicely with Synergy where the ability to spin up and down workloads dynamically could then be orchestrated intelligently.

Looks like that acquisition of Nimble is paying off already.

3PAR Remote Copy Failover

3PAR storage Remote Copy Failover, Recovery & Restore using IMC

Today we have a highly detailed guest post covering the 3PAR remote copy failover and recovery process. If you fancy writing a guest post check out this post.

About the author

Written by Deepak Garg, a technocrat with over 10+ years of experience in storage administration and with technical expertise in managing the technical support functions. Expert on HPE 3PAR, HPE StoreOnce, HP EVA Storage, HP MSA/P2000, LHN and many other HPE products


Unidirectional 1-to-1 Configuration

A unidirectional 1-to-1 remote-copy configuration is composed of one remote-copy pair. Each storage system in the pair plays only one role: one system is the primary system, and one system is the backup system.

Unidirectional remote copy rellationship

Bidirectional 1-to-1 Configuration

A bidirectional 1-to-1 remote-copy configuration is composed of one remote-copy pair.Each storage system in the pair functions as both the primary and backup system and each system contains both primary and secondary volume groups.

Each system provides backup for the other, according to the direction of replication specified for each volume group. Below figure illustrates a bidirectional 1-to-1 remote-copy configuration.

System Information during Failover for 1-to-1 Configurations

Asynchronous Periodic Mode for 1-to-1 Configurations

When a failure occurs on systems with asynchronous periodic mode volume groups such that all links between the systems are broken, the following actions occur:

  • After 60 seconds, the system marks the sending links as down.
  • After another 200 seconds, the system marks the targets as failed

Recovering from Disaster for 1-to-1 Configurations

For the remote copy failover, recover and restore operation there are defined steps involved which need to followed as below.

  1. Failover
  2. Recovery
  3. Restore


a) Stop Remote Copy Group    

Reverse the role of all volume groups on the system that is still in normal operation (the failover system). Here we will consider that system “System-A” is in failed state or having some planned maintenance activity. Below screen shot shows where we want to do the failover of replication group “DRTEST” from primary system System-A to System-B

During this first of all we have to stop the remote copy replication group “DRTEST” to do the testing.

From the 3PAR management console, click on remote copy from the left pane. After this click on the groups and verify the replication group listed on the right side as shown below in picture.

View 3PAr remote copy groups

We will be doing the failover of “DRTEST” replication group. So right click on “DRTEST” and click Stop Remote Copy Group(s) as shown below in picture:

Stopping the remote copy groups

Once clicked on Stop Remote Copy Group(s) option a pop-up window as shown below will open which will state that remote copy mirroring will be stopped. Click on OK to proceed.

Confirm groups are stoped

Once we stop Remote Copy Group, replication from source to target will be stopped.

b) Failover Remote Copy Group   

Once the remote copy group is in failed state then we will see that Group state is a stopped state. Now we have to right click on the failed remote copy group (in our case we are preparing example with remote copy group “DRTEST”) and click “Failover Remote Copy Group (s)..” option as shown below

Now one pop-up window will open click OK and after that one more pop-up will open and click yes here

Note:- After this failover will be executed for the selected group. The failover operation changes the role of secondary groups on the backup system (i.e. System-B) from “Secondary” to “Primary-Rev”. Any LUNs (VLUNs) associated with the volumes in the selected groups become writable by hosts connected to the backup system (backup system is System-B in our case). These VLUNs will be in writable permission from both side 3PAR so we must ensure that no write operation on VLUN from primary site.

As per picture below, click YES to continue and the failover operation will start.confirm fsailoverNow there should be Group state as “stopped” as per below picture. Replication status in the table will be as “Stopped” and Backup system (i.e. System-B) will show its role as “Primary-Rev” with DR state as “Failover”.

This completes all failover steps.


a) Description of Recovery Option    

Recover option will recover the failed system (in our case failed system is System-A). When both systems in the remote-copy pair are ready to resume normal operation, reverse the natural direction of data flow and resynchronize the systems.

At this time we have to right click on the replication group which was failed earlier (in our case it is “DRTEST”) and click on “Recover Remote Copy Group (s).. This will copy data / initiates reverse replication and synchronize the delta changes from the reversed volume groups on the failover system (System-B) to the corresponding volume groups on the recovered system (System-A).

Once executed the role of the remote copy group on the source system (System-A) becomes “Secondary-Rev”. Also, any LUN associated with the volumes in the selected groups become non-writable on the source system (System-A).

Note: – The recovery operation can be executed only on groups that have successfully completed the failover option.

b) Recover Remote Copy Group  

Below two pictures shows the process on how to put a replication group in recover state and then click YES in pop-up window. Right click on the replication group which was failover and click on the option “Recover Remote Copy Group(s)”

Recovering the remote copy groups

confirm recover operationOnce clicked on OK prompt, there will be one more pop-up, press yes now. Important to note that VLUNs will not be writable now on source system “System-A” and it will be in writable mode on backup system “System-B”.

Now, we should be able to see Source role for “DRTEST” on source system should be “Secondary-Rev” and “Primary-Rev” on the Backup system role as shown in below picture. Now the DR state will be in “Recover” statchecking status of recoveryc) Verification:

1 Issue the showrcopy command from the CLI on the failover system (System-B).Verify the following:

  • The Status of the target system (recovered system – “System-A”) is ready
  • The SyncStatus of all volumes in the Primary-Rev volume groups is Syncing.
  • The Status of all sending links is Up,

2 Issue the showrcopy command from the CLI on the recovered system (System-A) Verify the following:

  • The Status of the target system (System-B) is ready
  • The Status of all sending links is Up
  • The Role of the synchronizing volume groups is Secondary-Rev
  • The SyncStatus of all volumes in the Secondary-Rev volume groups is Syncing


a) Description 

Once the recovery is completed for the remote copy group then we must restore back the actual state of replication group. I.e. bring the replication group (in our case it is “DRTEST”) back to “System-A” as primary role and again replication from the primary system (System-A) to backup system (System-B).

b) Procedure to Implement

For doing this right click on the replication group and click “Restore Remote Copy Group(s)..”.This restore operation restores replication for the selected Remote Copy group to a pre-failover state after the recovery operation has been completed. Once the Restore operation is executed the role of the remote copy group on source system (System-A) will be “primary” and the Remote copy group on the backup system will be “Secondary”. Also, any LUNs associated with the volumes in the selected groups become writable by hosts connected to the source system (i.e. System-A) and become non-writable by hosts connected to the backup system (i.e. System-B)

And once we will click on the OK in the above pasted picture, then there will be one more pop-up to click Yes or No, we have to click “Yes” to complete the process.

Now the system should be able to see the status of restored replication group as it was in actual state. Below picture shows the actual status with System-A system as Primary and normal state and replication pointing from System-A to System-B.

3par replication status