Linux LVM snapshot

#11

On Mar 5, 6:50*pm, "Neil Truby" <neil.tr... (AT) ardenta (DOT) com> wrote:

Quote:

Correct me if I am wrong but with a SAN snapshot you can only recover to
the point of the last snapshot, but with HDR/RSS you always have a backup
system that is in sync with the Primary and can be made Primary in a few
seconds with a few simple onmode commands or automatically with oncmsm and
the failover arbitrator. *Does a SAN replicated image solve this problem
and is it just as good as HDR as far as recoverability is concerned?
(serious question, I don't know the answer)

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

With HDR/RSS you also get the benefit of a read only secondary (or
multiple secondaries) for reporting and can use updateable secondaries if
you want to make all of your HDR nodes appear updateable (all updates will
be sent to the primary, so this only gives the impression that all nodes
are updateable).

Yes, that is true, and a good point. But a subtle point here is that, if the
remote site is to be true DR from which you are likely to want to a remote
server which has lots of grunt. And any remote server you want to query
needs to be fully licensed rom an IBM software perspective. *Sure, you can
alleviate this impact through virtualisation, but there's one more thing you
have to reverse if you *do* fail over.

Add on top of this the benefit of HDR being an Informix feature that works
well with the application side (I'm thinking mostly about connection
redirection via sqlhost groups or the connection manager). *In my
experience HDR is pretty hands off once it is up and running, so the
administration overhead is pretty low. Also, HDR is something you have
control over vs. a SAN based solution where a sysadmin or storage admin
may have control.

Well, speak for yourself of course - our business model is wherever possible
to contrll all the infrastructure! *But, in an environment where
resposnibilities is tightly siloed, you certainly have a point.

When we migrated to a new storage solution, the SAN snapshot and
replication stuff required an additional license which we did not
purchase.

Yes, usually. *So indeed it's an extra cost to consider. *The generalpoint
about SAN replication is though that few of our customer sites are all
Informix these days, and SAN replication techniques can be used for
non-Informix databases and apps as well, which would tend to make it a lower
TCO option for multi-app sites.

Exactly as Neil says, in an environment that contains other RDBMSes
also, it may be overall simpler to use Recover Point as universal
solution that may provide CDP/ point-in-time restore for all databases
(and file systems also) of interest. At least, we in this news group
know that not all RDBMSes have replication mechanisms as good as HDR
is. For some apps, like Oracle, SQL Server or MS Exchange there are
readily available scripts; for others there is an API available to
access Recover Point for the purpose of marking points of consistency
etc.

BTW, being a SAN admin/UNIX sysadmin/RDBMSes DBA all at once, I wonder
what's it like to be a DBA unaware of how are your database chunks
stored. Is it easier not to worry about underlying server/SAN stuff or
one worries even more since he/she has no control of that?

Darko Krstic

#12

Quote:

BTW, being a SAN admin/UNIX sysadmin/RDBMSes DBA all at once, I wonder
what's it like to be a DBA unaware of how are your database chunks
stored. Is it easier not to worry about underlying server/SAN stuff or
one worries even more since he/she has no control of that?

What's the big deal? You just let the SAN admin give you a slice of that
giant RAID5 array that is shared by everyone and let the storage firmware
handle everything. I mean, that thing has a 16 GB cache so how could there
ever be a problem?

Andrew

#13

Andrew Ford schrieb:

Quote:

BTW, being a SAN admin/UNIX sysadmin/RDBMSes DBA all at once, I wonder
what's it like to be a DBA unaware of how are your database chunks
stored. Is it easier not to worry about underlying server/SAN stuff or
one worries even more since he/she has no control of that?

What's the big deal? You just let the SAN admin give you a slice of
that giant RAID5 array that is shared by everyone and let the storage
firmware handle everything. I mean, that thing has a 16 GB cache so how
could there ever be a problem?

Andrew

LOL

This was a good one. Andrew, you made my day!

The bitter truth is:
..... the thingy could have 16 GB cache, but as the greedy storage company
changes 16-32 times for 2x 4 GB of what you or me 'd pay in mail ordering it from
'Kaiser'-ston [ to not name a memory seller ] .... it only has 8 GB installed.

dic_k
*--- NO RAID 5 or 6 NEVER EVER ---*
--
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe

#14

On 5 Mar, 17:50, "Neil Truby" <neil.tr... (AT) ardenta (DOT) com> wrote:

Quote:

Correct me if I am wrong but with a SAN snapshot you can only recover to
the point of the last snapshot, but with HDR/RSS you always have a backup
system that is in sync with the Primary and can be made Primary in a few
seconds with a few simple onmode commands or automatically with oncmsm and
the failover arbitrator. *Does a SAN replicated image solve this problem
and is it just as good as HDR as far as recoverability is concerned?
(serious question, I don't know the answer)

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

Honestly these amateurs who give advice...

If the SAN is behind then when you flip over you will be missing disk
writes hence how on earth can you rollforward the logs?
"Oh that insert did not make it so the subsequent log record to update
it fails and oops my other copy will not come online".

You need to do an external backup and restore as per
http://publib.boulder.ibm.com/infoce...ds_bar_263.htm
and follow the rules at
http://publib.boulder.ibm.com/infoce...ds_bar_420.htm
including

"Suspend continuous logical-log backups before you block the database
server for an external backup. After the external backup is complete,
resume the continuous logical-log backup".

You ALWAYS need to ensure that IDS can sync the logs with the data
otherwise log roll-forwards will fail.

Quote:

With HDR/RSS you also get the benefit of a read only secondary (or
multiple secondaries) for reporting and can use updateable secondaries if
you want to make all of your HDR nodes appear updateable (all updates will
be sent to the primary, so this only gives the impression that all nodes
are updateable).

Yes, that is true, and a good point. But a subtle point here is that, if the
remote site is to be true DR from which you are likely to want to a remote
server which has lots of grunt. And any remote server you want to query
needs to be fully licensed rom an IBM software perspective. *Sure, you can
alleviate this impact through virtualisation, but there's one more thing you
have to reverse if you *do* fail over.

Add on top of this the benefit of HDR being an Informix feature that works
well with the application side (I'm thinking mostly about connection
redirection via sqlhost groups or the connection manager). *In my
experience HDR is pretty hands off once it is up and running, so the
administration overhead is pretty low. Also, HDR is something you have
control over vs. a SAN based solution where a sysadmin or storage admin
may have control.

Well, speak for yourself of course - our business model is wherever possible
to contrll all the infrastructure! *But, in an environment where
resposnibilities is tightly siloed, you certainly have a point.

When we migrated to a new storage solution, the SAN snapshot and
replication stuff required an additional license which we did not
purchase.

Yes, usually. *So indeed it's an extra cost to consider. *The generalpoint
about SAN replication is though that few of our customer sites are all
Informix these days, and SAN replication techniques can be used for
non-Informix databases and apps as well, which would tend to make it a lower
TCO option for multi-app sites.

#15

<david (AT) smooth1 (DOT) co.uk> wrote

Quote:

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

Honestly these amateurs who give advice...

Well obviously I'm not a true professional like you, David. I'm just doing
my humble amateur best ... ;-)

Quote:

If the SAN is behind then when you flip over you will be missing disk
writes hence how on earth can you rollforward the logs?

"Oh that insert did not make it so the subsequent log record to update

Quote:

it fails and oops my other copy will not come online".

Who said anything about rolling forward logs?

Quote:

You need to do an external backup and restore as per
http://publib.boulder.ibm.com/infoce...ds_bar_263.htm

and follow the rules at
http://publib.boulder.ibm.com/infoce...ds_bar_420.htm

Quote:

including

Why are you referring to backups and restores?

#16

Thanks to Neil and Art for the answers and everyone else for this discussion...

So, anybody use Linux* LVM Snapshot with Informix on production ?
Over primary or secondary (using the new resource of external backups).
Any comment?

--- Em sex, 5/3/10, Neil Truby <neil.truby (AT) ardenta (DOT) com> escreveu:

De: Neil Truby <neil.truby (AT) ardenta (DOT) com>
Assunto: Re: Linux LVM snapshot
Para: informix-list (AT) iiug (DOT) org
Data: Sexta-feira, 5 de Março de 2010, 21:40

<david (AT) smooth1 (DOT) co.uk> wrote

Quote:

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

Honestly these amateurs who give advice...

Well obviously I'm not a true professional like you, David.* I'm just doing
my humble amateur best ... ;-)

Quote:

If the SAN is behind then when you flip over you will be missing disk
writes hence how on earth can you rollforward the logs?

"Oh that insert did not make it so the subsequent log record to update

Quote:

it fails and oops my other copy will not come online".

Who said anything about rolling forward logs?

Quote:

You need to do an external backup and restore as per
http://publib.boulder.ibm.com/infoce...ds_bar_263.htm

and follow the rules at
http://publib.boulder.ibm.com/infoce...ds_bar_420.htm

Quote:

including

Why are you referring to backups and restores?

_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

__________________________________________________ __________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

#17

On 05/03/2010 17:50, Neil Truby wrote:

Quote:

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

I was going to ignore this, but on balance I won't

Neil - unless your rate of data change is VERY bursty then the above is
just wrong

The bandwidth requirement is the average rate of data change - no more -
no less

If your data is bursty then if you stick with the average bandwidth
requirement then yes your remote san will sometimes lag

In the real world (tm) use the 95 percentile and set your bandwidth
there as a minimum

Please don't confuse bandwidth and latency (offers grandmother an egg)

--
Clive

--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.

#18

On 6 Mar, 00:40, "Neil Truby" <neil.tr... (AT) ardenta (DOT) com> wrote:

Quote:

da... (AT) smooth1 (DOT) co.uk> wrote in message

news:45c07d4d-4c53-438e-a473-852194020cfe (AT) 33g2000yqj (DOT) googlegroups.com...

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

Honestly these amateurs who give advice...

Well obviously I'm not a true professional like you, David. *I'm just doing
my humble amateur best ... ;-)

Hee Hee!

Quote:

If the SAN is behind then when you flip over you will be missing disk

writes hence how on earth can you rollforward the logs?
"Oh that insert did not make it so the subsequent log record to update

it fails and oops my other copy will not come online".

Who said anything about rolling forward logs?

If x minutes after you snapshot you lose the building then you need
to rollforward x minutes of logs to get to up to the minute recovery.

Depending how often you snapshot the set of volumes 'x' minutes could
be several hours.

Quote:

You need to do an external backup and restore as per

http://publib.boulder.ibm.com/infoce...ndex.jsp?topic...
and follow the rules athttp://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic...

including

Why are you referring to backups and restores?

#19

"Clive Eisen" <clive (AT) serendipita (DOT) com> wrote

Quote:

On 05/03/2010 17:50, Neil Truby wrote:

Well, yes, with something like EMC Recoverpoint you can keep a remote SAN
copy in step with the original primary (the more seconds you allow the
remote SAN to lag, the lower the bandwidth requirement of course).

I was going to ignore this, but on balance I won't

Neil - unless your rate of data change is VERY bursty then the above is
just wrong

I don't think so.
But you might be right I suppose.
However, I didn't understand your explanation.

#20

<david (AT) smooth1 (DOT) co.uk> wrote

On 6 Mar, 00:40, "Neil Truby" <neil.tr... (AT) ardenta (DOT) com> wrote:

Quote:

da... (AT) smooth1 (DOT) co.uk> wrote in message

news:45c07d4d-4c53-438e-a473-852194020cfe (AT) 33g2000yqj (DOT) googlegroups.com...

Quote:

If the SAN is behind then when you flip over you will be missing disk

writes hence how on earth can you rollforward the logs?
"Oh that insert did not make it so the subsequent log record to update

it fails and oops my other copy will not come online".

Who said anything about rolling forward logs?

If x minutes after you snapshot you lose the building then you need
to rollforward x minutes of logs to get to up to the minute recovery.

Recoverpoint is a continuous remote replication product, not a snapshot
technology. So although you can use it for external backups, being careful
to block the primary first, it can be used just to replicate to a remote
site, preserving write order. So the db at the remote site can just be
restarted, and rely upon Fast Recovery to fire up. Furtehrmore it can be
used to do point-in-time recovery, argubaly much more quickly and easily
that onbar.

It's certified for all the usual dbs: Oracle, SQL Server, DB2 ... but not,
unfortunately, Informix. It does work with IDS though (although I've not
been able to try the point-in-time functionality for myself).