EV10 Upgrade Questions

[charles-k]

Hi all,

I'm putting together my action plan for an EV 8.0.3 => EV 9.0.2 => EV 10.0.1 upgrade, and have a couple questions.

1.  My current (32-bit) and new (64-bit) EV servers are VMs.  Before I start the upgrade/migration, I'm going to make a clone of the current VM to have as a rollback point in case I run into problems.  The question I have here is, do I need to clone the disk that holds the vault store partition?  Does the upgrade to either EV9 or EV10 in any way touch the archive data sitting in the vault store which would require me to undo the changes if I needed to rollback?  If the upgrades don't change the archive data at all, I'd rather not clone that disk since it's 800 GB.

2.  All data volumes on the EV server are SAN-attached, so instead of copying data, I'm going to just detach the vault store and index volumes from the old server and attach it to the new.  Do I then need to add a new volume for the 64-bit index, or can EV10 create the 64-bit index on the same volume that has the old 32-bit index?  Is there a best practice regarding index volumes for servers that have been migrated to EV10?

Thanks in advance for any guidance you can provide!

[JesusWept3 · Accepted solution]

1. My current (32-bit) and new (64-bit) EV servers are VMs. Before I start the upgrade/migration, I'm going to make a clone of the current VM to have as a rollback point in case I run into problems. The question I have here is, do I need to clone the disk that holds the vault store partition? Does the upgrade to either EV9 or EV10 in any way touch the archive data sitting in the vault store which would require me to undo the changes if I needed to rollback? If the upgrades don't change the archive data at all, I'd rather not clone that disk since it's 800 GB.

Nope, the only way it might affect the data is if you run collections or expiry and that kind of stuff
I know of a customer that upgraded from 2007 to 9, and they had to roll back to 2007 but there were files missing, and it turned out they were in CAB files, but because the databases were rolled back, the collections didn't exist in the vault store database.

So my suggestion would be to disable expiry, and disable vault store collections and maybe disable the site schedule altogether and test with small amounts of items when testing, then when you are absolutely sure the that the upgrade has been succesful, you can then turn everything back on..... that way if you do have to roll back for any reason, the data should remain largely untouched and in sync with the restore points you go back to.

That being said, its always best practice to have as complete and thorough backup as possible before any upgrades. 

2. All data volumes on the EV server are SAN-attached, so instead of copying data, I'm going to just detach the vault store and index volumes from the old server and attach it to the new. Do I then need to add a new volume for the 64-bit index, or can EV10 create the 64-bit index on the same volume that has the old 32-bit index? Is there a best practice regarding index volumes for servers that have been migrated to EV10?'

As far as physical drives go, you can use the same volumes, I would suggest though creating entirely new Index locations for the EV10 stuff, however when you are doing your conversions to 64bit, you are going to push through a lot of IO on to the index drives and the storage drives.

If you then couple that with any Initial vault cache synchronizations, expiry, regular user searches, any DA searches etc that hit the existing indexes, you may find that you are putting too much work on the single index volume.

You could if you wanted to, and if you had an extra VM, just create a dedicated Index Server, install EV and give it only the Index Service and Task Controller Service, and then add a new Indexing Group, and add the new index server to be responsible for your vault stores, you can have the new index server be responsible just for those indexes so you have an entirely different server looking after them, it will be more responsive in the long run

Would definitely recommend this if you are a heavy DA user

[charles-k]

JesusWept2,

Thanks for your prompt and thorough answers, I really appreciate it!

One quick question -- in your response about the EV10 index volume, you stated:

however when you are doing your conversions to 64bit, you are going to push through a lot of IO on to the index drives and the storage drives

Can you explain what you mean by conversions to 64-bit?  Are you saying that EV10 does some sort of conversion on the existing index and vault stores?

Thanks again.

[JesusWept3]

OK so basically when you upgrade to EV10 you are gonna have a whole slew of new indexing options and set up, and one of them is to "Convert" the indexes, basically its a rebuild, but it keeps the legacy index online and then creates the new users index seperately then when it completes it switches over.

it adds new things like in EV8 if you wanted to search for a word, something like
Enterprise with a wild card, EV8 you would do Ent? , you'd need at least 3 characters before
but in EV10 indexing, you can use * anywhere, you could do E*prise and it will return Enterprise etc

It is definitely in your best interests to get your indexes over to the new indexing engine (Velocity) rather than keeping them on the old indexing engine (FAST)

So yeah, Conversion = Rebuild of index to new indexing engine whilst keeping the old index online

 

[charles-k]

Thanks for the explanation!