Comprehensive data protection for all workloads
Post Reply
Djeten
Influencer
Posts: 11
Liked: never
Joined: Oct 30, 2009 11:21 am
Full Name: Didier Boydens
Contact:

Writeback through service console to FC VMFS volume

Post by Djeten » Dec 09, 2009 11:07 am

Gostev,

Ben Milligan from your support stated that following was correct:

Question:
If I understand you correctly the writing of a replica to a datastore is always channeled through the service console?
Only the reading is performed through SAN, even if it is SAN-Only?

It doesn't seem right to me since my veeam server has all the disks (from san) in its disk manager. So presented properly.
Why can't it write to those disks (vmfs volumes?)?

Answer Ben:
No, unfortunately we still cannot write to the VMFS volumes directly, we have to use the ESX host as a proxy to write to the VMFS volumes. LUNS carved out and presented as NTFS have no issue, it is the VMFS format.


Gostev?
Are there any thoughts about developments to write directly to VMFS because we have pure FC storage for replication. So no ISCSI or NFS.

Secondly, the service consoles do operate at max 100 Mbits/s while they are connected to an 1 Gb Nic? Is this a known issue?

We've encountered a slowdown in our esx-hosts this week because the esx 4.0-service consoles we're blocking the SAN connection. When rebooted the issue went away. Can it be caused by to much network traffic over the consoles? When we replicate, even though it is incremental, the datathoughput is still quite high. The veeam agent?

For the second part I'll make a support issue.

Thanks,

Didier Boydens
St. Augustinus Hospital Belgium

Gostev
SVP, Product Management
Posts: 24984
Liked: 3629 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Writeback through service console to FC VMFS volume

Post by Gostev » Dec 09, 2009 11:25 am

Hello Didier, Ben is correct - we cannot write directly to VMFS yet, it has to go throught the host. Most typical scenario for replication is writing to remote DR site, so in most cases it is different storage that Veeam Backup does not have direct connection to. So it is not in our immediate plans to add ability to write directly to target FC/iSCSI storage.

As for your second question, incremental replication passes transfer only changes since previous pass, so the amount of data should not be too high. But in all cases, the amount of network traffic cannot affect SAN connection anyhow.

Thank you.

Djeten
Influencer
Posts: 11
Liked: never
Joined: Oct 30, 2009 11:21 am
Full Name: Didier Boydens
Contact:

Re: Writeback through service console to FC VMFS volume

Post by Djeten » Dec 16, 2009 1:22 pm

Gostev,

We've had some performance problems for the write back actions through our service console. The performance was very poor.

I would like to present you the this best practice of Vreplicator wich we've implemented to Veeam (Thanks to Marino Simons Comparex). With immediate performance gains.

vReplicator
 
uses 
the 
ESX
Service
Console
 to 
control
 replication 
and
 also
 uses
 VMware
snapshot
 technology.



By 
default,
the
 ESX
Service
Console
 is 
significantly 
resource
 constrained, 
which
 can 
impact
 the
 performance
 of
 replication 
and 
snapshots.

For
 best
 performance
 of 
replication
 and 
VMware 
snapshot
 operations, 
increase 
the 
memory 
allocation
 of
 the 
Service
Console 
to 
800MB 
and 
CPU
Reservation 
to 
1500
MHz.


You 
can 
configure 
these
 settings
 through
 the 
VMware
 Infrastructure 
Client
 on 
the 
Configuration 
tab
 of 
each 
ESX
 host.



The 
settings
 are
 under
 “Memory” 
and 
“System
Resource
Allocation”.




The
 ESX
 Service
Console
 should
 have
 a 
dedicated 1Gbps
 network
 interface
 assigned
 to 
ensure 
adequate
 bandwidth
 for
 replication.


Sharing 
a 
network
card
 between
 the 
service 
console
 and 
virtual
machine
 network
 can
 impact
 on 
replication 
performance


Maybe it's a goog idea to share such a best practise in your manual when ypu implement replication. Even if it is incremental.

Thanks,

Didier Boydens

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 19 guests