Single Instance Storage question

[ANDREY_FYODOROV]

In version 9, if I do not enable some level of sharing in a vault store group, do I get ANY single instance storage at all?  Even at the vault store partition level (like it used to work back in version 7)?

[JesusWept3]

If you do not enable Vault Store Groups the sharing will just be at the vault store level, that changed in EV8 (its possible that its only partition level, but i'm pretty sure its at the vault store level), so you will not lose the SIS you are used to in 2007.

Really though from a space savings perspective, OSIS is the way to go, in a giant single point of failure perspective though, it may not be as desirable

(ie if you have 10 vault stores, if one Vault Store goes down, you only affect people on that vault store, but if you have a Vault Store Group and every vault store in that group etc, then that one vault store being down will affect everyone regardless of their vault store location)

[Michael_Bilsbor]

Hi,

This is a v rare case where JesusWept2 is incorrect(jet lag? :) )

Once you upgrade you no longer get SIS until your vault stores go into vault store groups. 

Mike

[JesusWept3]

.........................................

These aren't the droids you are looking for *waves hand*

[ANDREY_FYODOROV]

OK, so even to get SIS at the vault store level, I need to enable sharing in the properties of the group, which includes creating of an SIS database, right?

(And there is no such thing as a SIS at the partition level I guess)

[ANDREY_FYODOROV]

And we have 7 EV servers around the world, in one vault site, with one SQL database in a central location.

There is only one Vault Store per server.

After the upgrade from 7 to 7.5 to 8 to 9, we have one vault store group called "Default Upgrade Group", but I haven't enabled sharing yet.

[Michael_Bilsbor]

Hi, Check the help it should cover this but yes.you have to enable sharing to get any sharing. If many of those servers already have Storage Services on them then they will already be doing updates to SQL remotely which I expect impacts your ingestion rates. Generally speaking we don't suggest doing SIS over network as it means to read a message you may have different parts of the message SIS'ed on different servers which in your case would mean reading some of these attachments from across the network so not sure you'd want that. So on that basis from the v little info you've provided I would have each vault store in it's our vault store group so it only shares with the local data it's archived. It means you get a good level of SIS but not the cross server level of SIS but at least you avoid network traffic on recalling items etc. Just IMHO difficult to say without having full sizing information. Mike

[ANDREY_FYODOROV]

We have about 60 TB worth of data that we already archived in EV v 7.0, over the course of 3+ years.   :)

And we continue to ingest at a rate of 5-10 GB per day on our busiest EV servers. 

The problem with using SIS in v 9.0 for us that I can see is that we only have one central SQL server for all the EV databases, it is located in Europe.

So even if we turn on sharing for just at the vault store level, for example vault store in NY, the  NY EV server will have to constantly check against the SIS database in Europe.

I guess I can't have a cake and eat it too in this situation.

[FreKac2]

Is it a requirement that the SQL server is only to be hosted in one location/Europe ?

You could move the DB's to a different SQL server.

[ANDREY_FYODOROV]

In a way, yes, it is a requirement.  Or a constraint that we have to live with.

I have been thinking about this more...  Back in EV 7.0, we successfully managed to archive 60 TB worth of data, while the SQL server was the same SQL server in Europe... and all that time EV 7.0 used its old SIS methods, which I assume checked uniqueness against that SQL server - and everything worked OK.

So I guess we should be OK with version 9.0's OSIS running against that SQL server too.

I have enabled it, on per-Vault Store level.

[Michael_Bilsbor]

Hi,

Just as an FYI old method didn't use SQL quite as much as it now does so I expect some different in performance.

Mike