Shawn,
I have found it very important when working with EMC (or any vendor,
really) to very carefully verify everything they say, or ask to have it
explained so you understand it thoroughly. I don't mean to imply that
they lie about anything, but I have frequently seem them exaggerate
their claims. Here are a couple examples:
- The first time we heard about Avamar was at an EMC event where the
speakers whole thrust was that this was the best solution out there for
backing up lots of VMs. But as I said in my earlier post, right now it
is a terrible solution for VM if you want to use VCB. If you don't mind
installing and running the Avamar client directly on each VM you can do
that, but that is certainly labor intensive and VCB exists to get
customers away from doing that.
- There was a speaker at an EMC event that used a specific customer as
an example. They told about what great efficiencies the customer had
realized, and how great the deduplication was, and how much money the
customer had saved, and so on. They were extremely specific and clear.
Well, I asked our EMC rep if I could talk to this company so I could ask
them some questions about the their implementation. This customer
happens to be the same city as we are. After a couple days they came
back and explained that the customer hadn't actually bought Avamar yet.
They had evaluated it and liked what they saw, and were getting ready to
install some Proof of Concept gear. But that is miles away from the
impression they gave during this presentation.
These are isolated incidences, and things are not alway like this with
EMC. I am just saying, do your best to verify what you hear, or test it
for yourself.
Best Regards,
John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424
Toll Free: (866) 796-9226
Cell: (314) 750-8721
-------- Original Message --------
Subject: Re: [ADSM-L] TSM vs Avamar
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
Date: Wed, June 24, 2009 9:24 am
To: ADSM-L AT VM.MARIST DOT EDU
Wow, great info everyone.
The last note you put in there about there not having an archive
solution.
I can't remember the details now, but the sales guy said there was some
kind of archive feature involving VMware. Something along the lines of
creating a standard VM with the archive data or something like that. Do
you know what they were talking about? I should probably get more
details.
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
john.schneider AT COMPUTERCOACHINGCOMMUNITY DOT COM
Sent by: ADSM-L AT VM.MARIST DOT EDU
06/23/2009 05:40 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] TSM vs Avamar
Hi!
I am just finishing up a multi-month proof-of-concept for Avamar. It
has many benefits, but you need to keep in mind these things:
1) It is a disk-only solution, it has no tape backend. You will have to
scale your Avamar footprint to completely contain all your backups, for
however many days retention you need, so it all fits on one (or more)
Avamar grids. If you scale it too small, you are going to be making a
disk purchase to keep up. If you let it fill up, you are in trouble!
You can't just shove more inexpensive tapes into the library. On the
other hand, since Avamar's consumption of disk will be a tiny fraction
as much as disk storage pool, you won't have to buy as much disk to get
where your job done. Your consumption of disk is space varies widely
depending on or mix of filesystem, database, NAS data types, so get help
from EMC sizing the solution.
2) Avamar is RAIN technology (Redundant Array of Independent Nodes).
Each grid of nodes will require 1 node for administration (called a
utility node), and 1 spare. The nodes in the grid can contain either
1TB or 2TB. Redundant copies of that data are distributed across the
nodes in the grid. Although it will scale to bigger grids, best
practice is to keep the grids to around 14 nodes in size. This is not a
terrible thing, but can add significantly to the cost.
3) Avamar comes with replication built in. Replication can be one-one,
one-many, many-one. But replication takes time, and you should not plan
to do your backups during replication; the performance will be
significantly impacted.
4) Avamar also requires regular scheduled garbage-collection. They tell
me it typically needs to run 2-4 hours per day. During this time the
grid operates in read-only mode; you cannot do backups to it. So if you
have hourly Oracle archive log backups, or some such, you will have
build them to live without Avamar for these periods of time, because
garbage collection is a necessity.
5) Backing up VMs, because they are so similar to each other, sounds
like an idea application for deduplication. However, the VMWare VCB
proxy solution today is very bad. But in every Avamar presentation I
have been to, they completely gloss over how it really works. The way
it works today requires each separate VM to be in its own group and its
own schedule. In our case, with 600VMs, that was going to be a
nightmare. Sometime in the third quarter when VMWare comes out with its
next version of VCB, it is supposed to be much better.
6) It is not an Archive solution, so if you have multi-year long-term
archive requirements, you will be needing a separage solution for those.
Best Regards,
John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424
Toll Free: (866) 796-9226
Cell: (314) 750-8721
-------- Original Message --------
Subject: Re: [ADSM-L] TSM vs Avamar
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
Date: Tue, June 23, 2009 11:32 am
To: ADSM-L AT VM.MARIST DOT EDU
They do have hardware at the multiple sites for DR. This is a "hot" DR
site as opposed to a cold site that you can do with tapes. This does fit
our environment however. We have multiple data centers that are DR sites
for each other. Currently we use TSM with VTLs at multiple sites and
just
replicate with backup stgpools over the WAN. In reality, we run into
more
bad tapes than we do with bad disks. I can't remember if I've ever had
to
run a "restore stg" on a VTL.
We only use tape for long term stuff
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
NRodolfich AT CMAONTHEWEB DOT COM
Sent by: ADSM-L AT VM.MARIST DOT EDU
06/23/2009 12:07 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] TSM vs Avamar
What does Avemar offer for DR purposes? I don't know any customers that
are
ready to
totally rely on electrically powered disk drives as a DR solution.
------------------------------------------------------------------------
The recent CommVault topic inspired this one. Our EMC reps are doing a
good marketing job for Avemar. While I'm not necessarily looking for
ammo
to shoot them down, I am having trouble finding the negatives of Avamar
versusTSM.
The main marketing claims that interested me:
- Dedupe at the client. They also claim that since they can do it at the
client, the ratio they can achieve is much higher than Falconstor or
DataDomain backend deduplication.
- They have some kind of directory tree hash marking. The claim for this
is that if you have directories with millions of files, it will have
hashes for each directory level. If one file changes, it can detect
which
directory has changed through these hashes and will prevent complete
file
system scanning for every backup. Sounds like it's an alternative for
the
TSM journaling feature.
- They have some kind of Vmware appliance generation thing which they
use
to create long term archives assuming they won't fit on the million:1
deduped storage!
As far as the negatives go, number one seems to be no analog to the
independant adsm-l community. Which also seems to prevent finding more
negatives. Also, the pre-sales engineer is a former TSM guy, which was a
craft EMC move!
Anyway, does anyone know any other negatives for Avamar vs TSM? I'd like
to be able to ask more intelligent questions.
Regards,
Shawn
________________________________________________
Shawn Drew
Regards,
Nicholas
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in
error,
please delete it and immediately notify the sender. Any use not in
accord
with its purpose, any dissemination or disclosure, either whole or
partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall
(will)
not therefore be liable for the message if modified. Please note that
certain
functions and services for BNP Paribas may be performed by BNP Paribas
RCC, Inc.
|
