HPE EVA Storage
1827181 Members
2057 Online
109716 Solutions
New Discussion

EVA / BC : Can we trust in snapclones ?

 
Lothar Krueler
Regular Advisor

EVA / BC : Can we trust in snapclones ?

Hello,
we're planning a SAN consisting of 2 EVAs each 3 TB. Snapshotting and snapcloning is an important feature to us for making backups. Our software is based on Informix/Cisam-Files, not on a database. It is not possible to back it up online, so we want to kick off the users twice a day for creating consistent snapclones and then do the backup to tape. If we have to recover the last backup, we hope we can quickly mount one of the clones instead of the original, or in case of single file recovery to mount the clone elsewhere for copying the file to the original place.
Yesterday a consultant told us, that snapshotting/-cloning does not work on EVA. He sayed that he had to return nearly 150 EVAs because the taken snapshots/snapclones didn't work. I never heard about this before. Looking at the amount of 150 EVAs i think that some people must know about this. Can anyone tell us, if this may be an correct information ? The consultant seemed not to be a fool.
If we cannot trust in EVAs snapclones, our backup concept will not work and we have to search for another solution - probably without EVAs.

Can we trust in EVAs snapclones? Are there known problems ?

Thanks in advance
Lothar
Wissen macht zaghaft, Dummheit kann alles!
16 REPLIES 16
generic_1
Respected Contributor

Re: EVA / BC : Can we trust in snapclones ?

Id check with HP and your Software Vendor(s) that you are snapcloning first. The key basically is not having problems with open files that are backed up :). Certain apps and databases have hooks for this type of stuff. Also make sure its supported on EVA :) by both parties, but just my two cents. If its HPUX you could to LV splits and mirrors, but prob not as fast as a snapclone.
Lothar Krueler
Regular Advisor

Re: EVA / BC : Can we trust in snapclones ?

Hi Jeff,
thank you. We want to connect two rp3440-4 using HPUX 11.11 / 11.i v1. Later we're planning connection of Windowsservers too.

Kicking off the users means to me : Killing all userprocesses which might change the data-files. The users get a message, they know that they have 2 minutes to log off. After that the remaining sessions will be terminated by killing their processes. It's always the same time and i assume, that people who didn't log off are not really active that moment. They cannot login again until the snap has succeded.
Till now i'm using a cronjob for this with Online JFS Snapshots on two L2000 with two Autoraids 12H.

Using EVA i thought i have better possibilities by using BC snapclones.
Concerning the apps i think that i do a snapclone on closed files and i'm exspecting that works.

The main question is : If i make a snapclone from a consistent VG, will the result be a full, identical copy (at initialisation-time) or not and - can i mount this copy instead of the original VG (When it has really finished)?

The other question is : Are there lots of known problems regarding snapclones / snapshots with EVA?

Lothar
Wissen macht zaghaft, Dummheit kann alles!
Alzhy
Honored Contributor

Re: EVA / BC : Can we trust in snapclones ?

EVA BC/SnapClone only works within 1 EVA and not accross EVAs. Your consultant was probably expecting that he'll be able to BC accross 2 EVAs -- which is not simply doable. You can use a product called Continous Access (CA) but I do not know if that fits your bill.

So you can do snapshots accross EVAs.. your best bet will be to use VxVM.
Hakuna Matata.
Lothar Krueler
Regular Advisor

Re: EVA / BC : Can we trust in snapclones ?

A few days ago i got a phonecall by that consultant. Now he says that snapshotting / -cloning on EVA does work, of course, but his customers had so massive problems in performance by using overlapping snapshots that they gave back the EVAs. Every additional snapshot would decrease performance significant, because there were blocks to be copied. Other storages would link pointers. Instead of copying blocks the linking of pointers wouldn't cost any performance. He suggests NetApp or EMC to us

I think of keeping two snapclones on EVA, one at noon and an other at night, each 60 to max 200 GB. The two EVAs should be mirrord by CA. For having unique snapclones on both EVAs I have to make the storages consistant and then take the snaps simultaneously.

I belief, that the performance would increase to normal level after finishing snapclonecreation - right ? Can anyone tell me, how much the performance decreases while snapclonecreation runs and how long it would take ?

Regarding snapshots : I think performance of snapshotting might depend on the amount of changed datablocks - right ? This might be a problem with non-databased applications like our CISAM-system. Till now i'm using software snapshots (online JFS). So our backup takes 4 hours. While this time the snapshots take a total of 0.5 GB real space (might be 1 to 1.5 GB if production runs at night), concerning to 60 GB of snapshotted data.

Will the resulting decrease of performance really matter in our case ?
Wissen macht zaghaft, Dummheit kann alles!
Alzhy
Honored Contributor

Re: EVA / BC : Can we trust in snapclones ?

EVA/BC solution did not fit our bill because (1) you cannot do anspshots accross EVAs (2) performance and (3) reliability - since a single EVA can fail - if you have your backup snapshot set and prod set on the same EVA and you have a failure - then you're paralyzed.

Do not get me wrong EVAs are excellent arrays but you'll need a scheme to do mirrors/snapshots accross EVAs.. The only acceptable solution for us was to employ Veritas Volume Manager (better if you also use FlashSnap product).
Hakuna Matata.
Lothar Krueler
Regular Advisor

Re: EVA / BC : Can we trust in snapclones ?

Hi Nelson,
thank you. I'm not sure that i understand you right. Does that mean that simaltaneously BC-snapcloning
Vol1 to Vol2 on EVA1 and
Vol1# to Vol2# on EVA2
will not work if Vol1 on EVA1 is CA-mirrored to Vol1# on EVA2 ?
Wissen macht zaghaft, Dummheit kann alles!
Marek Smejkal
Frequent Advisor

Re: EVA / BC : Can we trust in snapclones ?

Lothar,

It looks the consultant prefers EMC and does not know well EVA. There are three types of snapclones: 1. fully allocated snapshot - space is reserved. 2. demand allocated snapshot (vsnap) - space taken depends on the changed blocks. 3. snapclone - complete clone copy of vdisk. All those three types are within ONE EVA box. For copy between two or three EVAs you need Continuos Access EVA. The types 1 & 2 does not take EVA resources or very little when there is a change. The third type of course takes resources during full copy, I do not know the copy speed now, but I can find it.
Lothar Krueler
Regular Advisor

Re: EVA / BC : Can we trust in snapclones ?

@Marek,
thanks. That's what i'm thinking too, but I don't really know it. CA-mirroring means to me Mirroring between both of the EVAs using Continuous Access. Perhaps i'd better mentioned that.

I'm very interested in getting real-life information about the duration of internal copy by snapcloning (type 3)and about the influence to the overall performance / io-rate of the EVA.
Wissen macht zaghaft, Dummheit kann alles!
Marek Smejkal
Frequent Advisor

Re: EVA / BC : Can we trust in snapclones ?

Snapclone is created max 60GB/h but that depens on the EVA config. For the EVA CA there are of course non EVA influences you can use HP estimator,there is at docs.hp.com document "CA EVA user guide performance estimator".
Marek
Alzhy
Honored Contributor

Re: EVA / BC : Can we trust in snapclones ?

Lothar,

CA and BC are two different products. BC is a single EVA solution - meaning it creates snapshots and snapclones on the same EVA (not accross EVAs). CA is a failover/mirroring solution -- NOT a backup solution if what you're after is the creation of backup copies of your data.

VxVM and ancillary options will allow you to do host-based and array independent snapshots and mirrors -- so you can mirror and snapshot accross arrays. EVA BusinessCopy simply cannot do this as it always needs the snapshot/snapclone space to come from the same EVA where your source/prod data resides. Aside from reliability issues - we experience problems with performance as there is this "levelling" process going on in the background whenever snapshots/snapclones are done. On the surface it may seem the snapshot/clones are done but on the background - the EVA is hard at work and busy doing its job and thereby affecting performance on the connected servers.

Hakuna Matata.
Mark Grossman
Regular Advisor

Re: EVA / BC : Can we trust in snapclones ?

Lothar,
we do full snapclones of Oracle DB and applications, so its a mix of db and flat files from 2 different hpux servers, consisting of 225GB raid5 vdisk, a 30GB raid1 vdisk, and a 25GB raid5 vdisk. This is a total of 285 GB which takes about 50-55 minutes to complete all.
We have not seen performance problem during these snapclones or heard from any customers complaining (and believe me they would complain). This is on an eva3000 with all 56 drives populated and runs all payroll, hr, financials etc.
I cannot speak to snapshots as we really don't use them in our environment for backups, nor do we have a second eva (yet) or use CA.
I would continue to research this and call in specialists from HP and other vendors and possibly visit sites in your area using these functions if possible.
good luck,
Mark


Lothar Krueler
Regular Advisor

Re: EVA / BC : Can we trust in snapclones ?

Hi,
thanks for your responses.
This might be my last reply for the next 4 weeks, i'll go for holidays next week. I'm still interested in your responses and will read them when i'm back.

Marek,

I didn't find the doc. Can you post a link, please ?


Nelson,

i think we're missunderstanding. The planned environment is :
Prod. System : 1 rp3440, 1 EVA
Standby-Failover System : 1 rp3440, 1 EVA in a room approx. 400 meters away.
Software : HP-UX 11.11, MC-ServiceGuard, Business Copy for EVA and Continuous Access for EVA, opt. SecurePath (EVA 3000).
The idea : everything runs on the prod. system and the prod. data are to be mirrored to the standby-failover EVA. The snapclones should be taken after creating a consistant state simultaneously on both EVAs. On prod.EVA the prod.data, on the other EVA the mirrored data. So , I think, there should be no loss of data if one of the EVAs fails. Reading your responses makes me feel, that this wouldn't work. The other question is: does the snapcloning of 60-200 GB twice a day really affect performance in a very hard way or is it moderate. Duration of one or two hours is acceptable to us, if useraccess is still possible.


Mark,

experienced information like your's helps. In our case we would start with 26 drives, this will be slower than your 56 drives.
Like i heard, CA-Mirroring between EVAs does not have an effect to EVAs performance.


Thanks in advance
Lothar
Wissen macht zaghaft, Dummheit kann alles!
Alzhy
Honored Contributor

Re: EVA / BC : Can we trust in snapclones ?

In that case, if you have a standby system served by another EVA and CA is in the mix - then that's the "proper" use of your EVAs.. you should be protected.

Regarding my doubts with BC as a single array snapshot/snapclone solution -- I still have doubts. If your EVA serves only 1 or 2 servers that are really not that heavily loaded -- then it will probably suffice.
Hakuna Matata.
Lothar Krueler
Regular Advisor

Re: EVA / BC : Can we trust in snapclones ?

Marek,

thanks, i'll try (the docs and enjoying vacation).


Nelson,

thanks. Another consultant recommends a EVA4000 solution, like i described above, too, but he told me not to use CA with HP-UX, it would be better doing hostbased softwaremirroring with HP-UX MirrorDisk, because in case of failure of prod.EVA LVM would simply use the alternate paths to the other EVA and the apps would not get in trouble.
With CA a downtime would be essential for configuring SG-packages and so on. That would not be the High-Availability i want to get if i buy two systems!
Windows-Servers would need CA and SecurePath.
The CPU-usage of MirrorDisk wouldn't hurt.
Regarding BC: he knows about performance problems in using businesscopies of businesscopies. However, i don't know why to use that, but maybe others have to.
Wissen macht zaghaft, Dummheit kann alles!
Marek Smejkal
Frequent Advisor

Re: EVA / BC : Can we trust in snapclones ?

Lothar,

Beauty of CA is that performance overhead of copy is within the EVAs and not the unix systems. There can be more solutions to your demand, lvm mirroring is also an options (license needed). Only I do not understand in case of SG switch any delay with CA. If you are using synchronous CA (latency of 400m link is minimal) you have the same data on both EVAs. Then SG switch takes the same time. But we are somewhere else than original Q.

Marek