Got in yesterday (6/28/2010) and planned to attend an afternoon session but I got hung up on a few items that required my attention.  Attendance looks pretty good, food was a bit weak this AM but I am more of a coffee only person in the morning so not a huge deal for me.  Internet connectivity is stellar thus far hopefully this keeps up.  Looking forward to the sessions this week, I am starting the week with a session on entitled Mastering IP Subnetting Forever.  I will be blogging as always from the sessions I attend.  TTFN

Avamar DS18 = Utility Node + Spare Node + 16 Active Data Nodes

For a 3.3. TB Gen-3 Grid

• Raw Capacity ~102 TB
• Spare Node ~6 TB
• RAID5 ~15 TB
• Checkpoint  / GC ~28 TB
• RAIN ~3 TB
• Available for Active Backups ~49 TB

RAID Configuration:

• RAID 1 for 3.3 TB node
• RAID 5 for 2 TB nodes
• RAID 1 for 1 TB nodes

How to calculate the required capacity:

• Seed (Initial backups)
  Daily Change * Rentention in Days
  +RAIN = GSAN Utilization

• Need min available space for 4 checkpoints
• 3 checkpoints maintained by default

Data Gathering

Note:  Agent only vs. data store depends on the desired RPO

• xfer_rate = Gb/hr * .70
• date_size = total of the data set to be backed up
• restore_time = data_size x .65 / xfer_rate

If RTO < restore_rate then data store else agent only

Always use 3.3 TB nodes when configuring unless additional nodes are required to increase the ingestion rate.

Use the default de-dupe rate unless a POC or assessment has been performed.

Sizing Considerations:

• Data Types
• File Systems
• Databases
• Large Clients > 2 TB
• Dense File Systems (excluding EMC Celerra and NetApp)
• Organic Growth
• RTO
• Replication Window
• Maintenance Window

Non-RAIN node must be replicated this includes single node Avamar deployments and 1×2 (1 utility node and 2 data store nodes – this is non-RAIN config) configurations.

**** Remember this: As a general rule it seems that transactional databases are better suited to be backed up to Data Domain and NOT with the Avamar as the hashing of databases is generally very slow.

VMware (specifically using the VMware Storage APIs) and CIFS are well suited for Avamar

Data save rates:

• 100 – 150 GB/hr per avtar stream on latest server types
• Note:  it is possible to launch multiple avtar daemons with some tweaking, but an out of the box install only launches a single avtar process.
• VMguest backups can be slower (very scientific, these are backups that
• Default assumption is chuck-compress-hash process runs at a rate of 100 GB/hr
• This is the process that bottlenecks database backups (ideally is seems that the avtar stream rate should match the check-compress-hash process)

Scan rate:

• ~ 1 million files per hour
• 1 TB of file data will take about 1 hour to backup
• 1 TB DB will take ~ 10 hours to complete

Performance:

• 1 TB/hr per node in the grid (all file data)
• 80% file (800 GB file) and 20% DB (200 GB DB) and the performance level drops off to .5 TB/hr
• E.g. – DS18 perf will be ~ 15-16 TB/hr
• Per node ingest rate ~ 8GB/hr

Restores:

Data Fetch Process

• Per node assumption
• Chuck size 24kb
• each chunk is referenced in a hash index stripe
• Speed:
• 5 MB/s
• 18 GB/hr (compressed chunk)
• 25 GB/hr (rehydrated chunk)
• E.g. – A DS18 will restore at a rate of .5 TB/hr

NDMP Sizing:

• Size of the NDMP data set
• Type of filer (Celerra or NetApp)
• Number of volumes, file systems, qtrees
• Size of volumes
• Number of files per volume / file system

L-0 Fulls on happen once (we don’t want to size for them)

Size for L-1 incremental which will happen in perpetuity following the completion of the L-0 full.

• Important L-1 sizing data
• Number of files in the L-1 backup
• Backup window

2 Accelerator Nodes

NDMP throughput ~ 100 – 150 TB/hr

Assumed DeDupe Rates:

• File data
• Initial backup:  70% commonality (30% of the data is unique)
• e.g. – 30% of 10 TB = 3 TB stored
• Subsequent backups:  .3% daily change
• e.g. – .3% of 10 TB = 30 GB stored per day
• Database data
• Initial backup:  35% commonality (65% of the data is unique)
• e.g. – 65% of 10 TB = 6.5 TB stored
• Subsequent backups:  4% daily change
• e.g. – 4% of 10 TB = 400 GB stored per day

Tip:  Based on scan rate and the amount of data stored for DB backups you can see why Avamar may not be the best choice for DB backups.

NDMP Tips:

• Avamar NDMP accelerator node should be on the same LAN segment as the filer and the same switch when possible
• No Include/Exclude rules are supported
• Able to run up to 4 NDMP backups simultaneously
• most effective with large files
• min of 4GB of memory per accelerator node per stream
• 4 NDMP simultaneously scheduled as groups backups

Desktop / Laptop

Sizing:

• Number of clients
• Amount of data per client
• user files
• DB/PST files

DS18 can support ~ 5000 clients

Number of streams per node default is 18 (17 are usable, one should be reserved for restores).

That completes the brain dump.  Wish I had more but that is all for now.

If you have not heard EMC announced a product called VPLEX at EMC World 2010 this week.

Note:  I was watching and documenting at the same time so feel free to make any corrections to the data below.

What is the VPLEX recipe (what am I tasting in the session):

• 1/4 tablespoon storage vmotion capability in a geo dispersed deployment model
• 1/4tablespoon EMC Invista
• 1/4 tablespoon V-Max engine
• 1/4 tablespoon FAST

What you get:

• Datacenter Load Balancing
• Disaster avoidance datacenter maintenance
• Zero-downtime datacenter moves

The concept of VMotion is facilitated by the the presentation of a VPLEX Virtual-Volume.

Some infrastructure details:

• Up to 8 VPLEX directors per cluster
• Peer relationship
• 32GB of cache per director
• Cache coherency is maintained between the peer VPLEX’s

VPLEX Metro is a geo dispersed cluster-pair that presents one VPLEX virtual volume across data centers.  Read I/O benefits from local reads when accessing a VPLEX virtual volume.

Requirements/Rules:

• Implementation is synchronous
• 100 km distance limit
• < 5 ms of round-trip latency
• Stretched layer-2 network (Check out OTV to avoid STP issues associated with stretched layer-2 networks)
• shared layer-2 broadcast domain
• Do not stretch VMware clusters between data centers
• Used Fixed policy with VMware NMP
• Storage VMotion should be used for non-disruptive migrations

Simulation/Example :

• 2 data center separated by 100km
• Shared VM and VMotion networks
• Shared data stores through VPLEX metro
• Two node ESX cluster at each site with a single vCenter hos
• PowerPath/VE and set to adaptive
• Presented 500B LUNs presented directly
• Storage VMotion used for non-disruptive migration
• No storage resignaturing as this is only required on ESX 3.5
• more stuff i did not get…

Testing was performed on MOSS 2007, SQL Server, SAP and Oracle using workload simulation tools.

Test Scenarios:

• Scenario 1:Vmotion between 2 data centers in a VPLEx environment compared to a stretched SAN
• Result 1:  Storage vmoton followed by vmotion in stretched san took approcimately 25x longer than a Vmotion using a shared VPEX lun
• Scenario2 :  Vmotion between2 data centers with VPLEX separated by 100km
• Result 2:  Vmotion perf was well within the m specs and did not impact app perf or user experience

Note:  With these requirements this technology will pretty much be relegated to enterprise class customers with dark fibre between sites. With that said technology looks pretty cool if you can afford the infrastructure.

According the The Storage Anarchist’s blog “VPLEX comes to market with two mainstream customer references: AOL and Melbourne IT (who will be replacing their sheep farmer-endorsed product with the more applicable VPLEX)”

Check ot the VPLEX/VMotion Whitpaper

Well, I have pretty much gotten my ass kicked by EMC certification exams this year.  Day one Centera exam was a big miss (kind of expected this one), BRS TA E20-329 was a near miss yesterday, 28 questions of 70 on Avamar and Data Domain, wonder if this provides any insight on the future of Networker, considering on the previous BURA TA the majority of the questions were Networker questions I find this pretty telling.  This morning a near miss on the RecoverPoint E22-275 exam, 1 of 7 on the Brocade SAS section (ouch), but who the heck uses Brocade fabric splitters?

Anyway, hopefully I can get a win this afternoon, feeling pretty beat down, my cold is not helping.  I wonder how much Sudafed I can take before I damage vital organs

• Available later this year (2010)
• Aligned with FAST: “Place data on the most appropriate storage resources”
• Temporarily relocates often-used data to faster storage resources
• Provide Flash drive performance to hottest data
• Reduces load and improves performance of other resources
• Fully automated application acceleration
• Performance proposition
• Large enough to contain a high percentage of working set over long time intervals
• Fast enough to provide order of magnitude performance improvements
• Traditional DRAM cache vs FAST cache
• DRAM cache limited in size and very fast 10^-9
• 15K FC disk drive 10^-3
• Flash drive 10^-6
• Requirements
• FLARE R30 Required for FAST Cache
• Dedicated FLASH drives
• Native mirrored protection for read/write cache
• Can be unprotected for read cache only
• Implementation
• Memory map tracks host address usage and ownership
• 64kb extents (not LUN movement, much more granularity)
• All I/O flows through the FAST cache driver and memory map
• Memory map lookup is very low impact
• Memory map does take some DRAM space so there will be marginally less DRAM cache available (~ 1 GB of DRAM per 1 TB of FAST Cache)
• No “FORCED FLUSHING” so for bursty work loads that invoke traditional DRAM forced cache flushes this may help.
• Background process runs on CX to cleanup the extents
• Benefits
• Flash Cache read hits = Flash drive response times
• Flash Cache write hits flush faster
• Flash Cache hits offload HDDs
• Lower net application response time enables higher IOPs
• Efficient use of Flash drive technology
• Key concept for max Flash cache benefit
• Understand Locality of Reference
• Total GB of actively reference data
• Same areas reference over short periods and multiple times
• What makes for a good Flash cache workload
• Small to moderate working sets
• High frequency of access to same chunks – rehits
• Perf limited by disk technology not SPs
• Profiles of common apps
• DB OLTP/DSS
• Oracle, MS SQL
• Exchange
• File Servers
• Determine appropriate subset of LUNs for use with Fast cache

Note:  Sequential workloads are still (typically) better served by traditional rotational media  (e.g. – backup-to-disk)

• Tools
• FAST cache analyzer
• Will require RBA traces for FAST cache analysis
• Uber tiering with FAST cache plus FAST
• DRAM cache  <-> FAST cache <-> FC <-> SATA
• FAST Cache is a license so the CX enabler will be required (there is a bundle for both FAST and FAST cache)

Questions:

• Are you limited to 2 TB FAST cache?  Can you have multiple FAST cache LUNs?
• No limited to 2 TB really depends on how much DRAM capacity you want to consume with the memory map
• Limited to a single FAST cache LUN