Historical performance monitoring of SANsymphony - the easy way

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active

When I started to work with SANsymphony there was a tool called SANMaestro. It was a horrible expensive tool that collected performance statistics and draw some graphs you could easily understand without studying the internal performance counters. Since SANsymphony-V v8 the tool was gone and to be honest, I don't missed it a lot. Unfortunately there was no successor of this tool and v8 was unable to do more than real-time performance monitoring. In later versions historical monitoring was added by using internal or external SQL databases but I was never really satisfied with the stability and the way the metrics were displayed. So I started to invest some time in using other tools like ICINGA and ICINGAgrapher. We used powershell to get the metrics but this is incredible slow and also caused some management engine lock ups. The whole solution was hard to implement and even harder to maintain, nothing you want to have in several customer environments where you use the data to advise customers buying additional storage or help them understand their storage environment.

A few weeks ago I was on a FUJITSU storage roadshow and the speaker promoted support of a tool called Stor2RRD for all their ETERNUS storage systems. For all who know the ETERNUS family, there is  an external tool, SF Cruiser, that can be used to collect and store performance data. The "light" and free version only collects and shows performance data for the last day and the paid version is in the x-thousand Euro region for each storage system. Quite expensive if you have several ETERNUS systems under SANsymphony.

Read more ...

DataCore iSCSI best practice guide

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active

It's been a while since my last blog entry on this page. Don't worry, I'm still alive and will keep this blog updated but other things were more important the first weeks of the year so I disregarded my blogging a bit.

Back on track I will give you a short information about a "new" best practice guide from DataCore. For a long time DataCore was a bit close-lipped regarding iSCSI configuration recommendations. Obviously they focused on FC installations and handled iSCSI as a "should work right out of the box" setup. I remember opening a case and asking support about jumbo frames a two or three years ago. This case is still open.....

But in the meantime DataCore did their homework and created a perfect guide for iSCSI implementations. The main sentence still is "everything should work out of the box" but the details followed by this main sentence are quite detailed. They talk about jumbo frames, receive side scaling, latencies etc. in this 10 page document and it's worth reading it for all DCIE who are about to install iSCSI based SSY-V solutions.

For all other guys like admins this guide is also a must-read and gives you some valuable background information on iSCSI protocol.

You can get the guide at https://datacore.custhelp.com/app/answers/detail/a_id/1626 (you will need a support login to view or download this guide).

Rebooting DCS without stopping virtualization is OK

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

One of the benefits, Windows Server 2012 and above brings to Datacore's SANsymphony software is the possibility to reboot the Windows OS without prior stopping of Datacore's virtualization in the GUI or via powershell. Formerly you had to stop the virtualization in the correct way to avoid an "unexpected shutdown" and thus a full recovery of all your vdisks. Since Server 2012 this is not mandatory anymore. It is still the best way to do a reboot of your DCS but if you forget to do so you won't be out of redundancy for a quite long time anymore.

The reason behind the new possible "way" to reboot a DCS is the way Windows handles tasks and services during a reboot or shutdown call. All Windows versions prior 2012 gave each service a maximum shutdown time of 30s. After the 30s the process was killed and the server shutted down. 30s was to fast for the DCS service to flush the cache to disk and stop gracefully so you got an "unexpected shutdown". Newer Windows Server versions offer the running services the ability to block the shutdown process for a longer time before it will be killed so the DataCore Executive service has enough time to shutdown gracefully.

Unfortunately this new "feature" isn't documented anywhere in the official documentation and I only got the information from support after we "lost" the DCS because Windows Update wasn't disabled and the hosts were rebooted due to patch installation. After the systems came up again, all vdisks had a log recovery and the environment was clean after a few minutes.

I have no bullet proof OK from Datacore support to forget stopping SANsymphony in the GUI before rebooting or shutting down Windows Server so I will probably keep stopping it the "old fashioned way" and still have Windows update being disabled to avoid automatic reboots but I feel much more secure to be sparsed by unneccessary full recoveries as before.

SSY-V: speed up disk removal from pool

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Sooner or later there will be the requirement to remove a physical disk from a DCS disk pool. The default way to remove such a disk is to idetify the disk (this is probably the most challanging moment in the whole process), right click on the disk and select "Remove from disk pool"

 

remove pooldisk01

 

DC then automatically starts to move used SAUs to other disks in the pool. During this removal process, the disk will stay in the pool and looks like any other disk but if you look at the details of the disk you will see:

Read more ...

SSY-V: livestop only with password with v10 PSP4 and above

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

For all DCIE the livestop command is a very powerful and often used command to bring the SSY-V software back on track. The livestop command restarts the management services of SSY-V without affecting the storage virtualization layer, so I/O still can pass the system. Formerlay wirh SANmelody or SANsymphony the virtualization layer and the management layer were backed by two different services, so one was able to restart one of them without the other. With SSY-V DataCore merged both functions into a single service making the restart of the management a bit harder to do.

Livestop is normally required by the DataCore support whenever you open a case and something is wrong on the management layer. Unfortunatley in some of our installations livestop is rather common because we heavily use the Powershell to gather information about the DataCore environment to use them in ICINGA/Nagios. Although Datacore offers tons of perf counters but the ones we need aren't native available so we have to calculate them by getting data with powershell and combine them to get what we want.

The powershell implementation seems to have some kind of memory bug because after a while (and this can be only a few days), the management services denies access via powershell. I already wrote about this problem here.

Read more ...

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

Read more ...

SSY-V: A time out has occurred while recording performance data

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Two of my customers complained about an error after recent DataCore SSY-V updates that fill up their event logs in the DCS GUI.

The error is:

WARNING: A time out has occurred while recording performance data. This could be a result of insufficient processing resources on the selected recording server. Reduce the amount of counters configured in the recording session or select a recording server with sufficient processing resources

I checked all settings but no performance recording was active. To be more specific, not even a recording server was configured. In one environment I'm pretty sure there was never such a recording configured.

Concerned about unneeded I/O on the DCS or any buffer overflow I talked to DataCore support and they told me that this is a known issue with recent SSY-V versions and that this problem is probably coming from formerly configured recordings that are not properly imported in the new config. These error messages are annoying but not harmful at all so you can simply ignore them until the problem is fixed within a new PSP. By the way, even with PSP4 update 1 the problem still exists.

Hope PSP5 that is planned to be available within the next few days the problem is solved.

Datacore vDisk design

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

With server virtualization becoming more and more mainstream and new hypervisor versions supporting several TBs of maximum LUN size, one could think that vdisk design is getting more and more unimportant. This should be especially true with SDS like DataCore's SANsymphony-V as these software products pool all available physical disks into a central pool from which all vdisks are created. At a high level a pool is only a simple RAID0 across all available disks so all data will be distributed evenly across all these disks. So why not simply create a single huge vdisk and put the maintenance effort on a real low level? Beside the fact that this woul put all your data at risk if you have a problem with this single vdisk there are some more facts to consider.

Read more ...

Subcategories

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