What's new in SANsymphony-V 10 PSP3/4

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

With PSP3 released mid August 2015 and PSP4 probably coming within this week DataCore added once more some new features. The two PSPs foolow quite short after each other. The reason for this is that PSP3 adds some minor features but critical bugfixes and PSP4 adds bigger features but depended on certification from VMware so it was a planned short period of time between PSP3 and PSP4. Normally both PSPs would have been merged together.

As PSP3 is quite "old" and there are several articles around the features and bugfixes I will mainly focus on PSP4. Regarding the new features, there are currently 4 major announcements:


  1. Support for VMware vVols
  2. New support relay for uploading support bundles to DataCore
  3. Isolation of "bad performing" disks
  4. Frontend port overload monitoring


Let's have a look at these new features.

Support for VMware vVols

VMware introduced the concept of vVols with vSphere 6.0. vVols are a new way to provide storage for VMs. Before vVols, all VMs are stored in datastores. Datastores are made from LUNs where the storage admin decided the size, performance and availability characteristics. The concept of datastores is well known but introduced some problems. VMware admins always depend on the storage guys and they have to tell them what exactly they want. The storage guys have to understand this and create storage in the right way. This takes time and can be error-prone. vVols on the other side are much easier to handle and, once implemented, the VMware admin can simply carve out space for his VMs by simply defining space requirements and choosing from initially configured storage profiles. So with vVols you can get a policy-driven storage system where you can self-define yourt storage needs without involving storage guys all the time.

I already wrote about vVols in one of my articles and the concept is exactly the same for vVols with DataCore. Unfortunately PSP4 isn't available yet so I can't give you some screenshots or install instructions but I will do taht as soon as PSP4 is released.


Support relay

Troubleshooting SSY-V installations often need the official DataCore support team to get involved. The first thing they ask is to get a new support bundle to check logs and all that fancy stuff. Uploading these support bundles was a mess as the inbuild upload functionality only worked if your DCS had direct internet connection. Nothing a security-interested customer would ever do. So your only chance was to create the bundles, copy them to a system with direct internet access, rename the files to reflect the incident number and then upload the files via FTP to Datacores FTP server.
There was a while bunch of feature requests to solve this problem and the solution is now here. The support relay module can be installed on any Windows based server (physical or virtual) that has a direct internet connectiona s well as access to the DCS servers. That way, the bundles will still get created on the DCS but automatically sent to DataCore via the relay server. Currently the implementation guide recommends a sever with two NICs, one NIC in the DCS management subnet and one within the DMZ or wherever the system can get internet access. I already know that our security guy in the company will never let such a setup get implemented as the system could potentially be compromised and thus building a bridge between an internal and external network but there are surely better ways to solve this setup, e.g. by sending the traffic between DCS and proxy through a firewall.


Isolation of "bad performing" disks

The third feature in PSP4 will be an isolation feature. Currently, if you have a fully mirrored setup and something went wrong on one side on the physical backend. This could be for example a disk error or bad performing storage system or whatever. Let's take a disk failure and imagine your real-time application running on top of a vDisk that is based on the affected RAID set. The storage system will start rebuilding the RAID causing high latencies and slow performance on the logical disk. But this is only true for the side with the bad disk. The "good" side still could work with full power. As you have synchronous mirroring the slower side will slow down the entire vDisk, especially in a write-intensive setup. This way you will suffer performance on both sides even if only one side is affected but the other side could perform well.
DataCore implemented a feature that you can use in such a scenario so temporarily pause the mirroring and only let the good side be active as long as the performance impact exists on the other side. This will give your application the best performance you can offer. The dark side of this feature is that you loose data redundancy as the mirror is paused. During this time you should really take care that the "good" side won't run in any problems.

I think this "feature" is nice to have but I wouldn't recommend it in a general way. Data security is more important than the last percent of performance. But if you are in a situation where you really need the performance then this feature can help you a lot. As the mirror is only paused, there will be only a log recovery after disabling the new feature and you can do it on a per vdisk base. 


Frontend port overload monitoring

The last feature does what it already tells you. Why is this important? DataCore support checked their incidents and with steadily increasing speed of the backend storage devices and number of hosts that receive storage from the DataCore system, the frontend ports are sometimes the bottleneck. There is a performance limit for every FC port and if this limit is near, the FC port starts sending SCSI BUSY frames to the servers to tell them that the storage system can' serve the incoming requests. As this control frame is an inbuild feature in the FC/SCSI protocol there is normally no monitoring and thus you won't see such frames being sent from the FC target. PSP4 now implements a mechanism to oberserve the FC frontendports and check for such SCSI BUSY frames. An alert will then be automatically triggered to inform the storage admin. But this is only an alert, there is no automatic solution for this problem. You can solve it manually by adding more FC ports or rebalance your application servers across all available frontend ports.
Please keep in mind that this monitoring is only available with FC frontend ports. There is no support for iSCSI at the moment.


joomla templatesfree joomla templatestemplate joomla
2019  v-strange.de   globbers joomla template