Thursday, July 24, 2014

Why I feel Hybrid SANs aren't necessarily the full solution for VDI storage

In the early days of VDI, storage immediately became a pain point in any virtual desktop implementation using a SAN.  Basically the only way to get the IOPS up to an acceptable level was to add more disk spindles, regardless of whether or not more storage space was actually needed.  More recently hybrid arrays have become all the rage that use fast SSD caching to cache common reads and often buffer writes before it gets written to the traditional spinning drives.  The prices on hybrid arrays are often also extremely competitive with traditional arrays and way cheaper than going all flash....

So simple decision right?  Go hybrid and problem solved?

Not so fast.....  VDI isn't the same beast as serving databases and web pages.

I have personally seen instances, due to the write "IO blender" effect of hundreds of virtual desktops doing many different things, effectively flood and fill the SSD's of a hybrid array with writes which resulted in the overall performance of the array to fall dramatically and caused latency to increase as the array struggled to flush the SSD cache to spinning disks (so we're back to the original problem) in an effort to free space to cache more writes.

My thoughts on a true solution?  Well I think I've found a few.... and which I'll soon post about each separately in the future.

Friday, July 18, 2014

Purging old events from the View Events database

Do you have a lot of non-persistent floating pool desktops that refresh on logoff?

Do you point View Administrator to a SQL Event Database to store historical events?

If so, I've found that the database can get quite big as it seems to basically keeps events forever.

There are VMware KB's for purging the vCenter database of old records, but nothing for View Events.
Then I found the following SQL query on the VMware Community boards:
delete from [View-Event].[dbo].[v_event_data_historical] where EventID in (select EventID from [View-Event].[dbo].[v_event_historical] where Time < DATEADD(day,-30,getdate()))  
delete from [View-Event].[dbo].[v_event_historical] where Time < DATEADD(day,-30,getdate())

and I changed it to the following for my needs:
delete from [ViewEvents].[dbo].[viewevent_data_historical] where EventID in (where EventID from [ViewEvents].[dbo].[viewevent_historical] where Time < DATEADD(day,-365,getdate()))

delete from [ViewEvents].[dbo].[viewevent_historical] where Time < DATEADD(day,-365,getdate())
Where [ViewEvents] is the name of my Events Database and since I have the table prefix set as "view" in View Administrator,  [viewevent_data_historical] and [viewevent_historical] are the names of the tables that need to be purged of old events.  If using the above, you'd need to modify those to your table names.  

Also note where I changed "-30" to "-365" which is where you specify how old the data has to be to be deleted.  I chose 365 days as a safe starting point because 1 year's worth of old Event data is more than I'll ever need, but it's still there if I need to review the past year for some reason.

Even keeping 1 year of data reduced my ViewEvents database size from almost 20GB to ~7GB once I performed a database shrink after running the query.  There were at least 2-3 extra years of accumulated old data.

One last thing, if you don't have a lot of disk space and this is the first time running the cleanup, change your logging of the database to Bulk-logging or you'll run out of drive space with all of the transaction logs before it completes.

I also ended up setting up the above query to run as a weekly maintenance cleanup job to keep the Event database size consistent over time.