How many times do you get asked “how do I work out if VM Replication will work with my internet link” Well I wanted to demonstrate some way of providing a calculator without working it out in my head every time. So I made a Replication Calculation tool. It is assumed that you provide it with 3 values:
- Average Rate of Change.
- The Link speed – this value should reflect the upload speed at the source site or the download speed at the target if this is less. So for example if the upload at the source is 6Mbs and 10Mbs download at the target then go for 6Mbs
- Bandwidth % – which is the amount of bandwidth as % which achievable from the link speed specified.
So how do you work out of the “Average Rate of Change” Well if you are using products like Veeam Backup you can monitor a local backup or replication for a period of time which will give you a good indicator of Rate of Change.
If we look at the properties of a completed backup job:
You can monitor the size of the delta’s (.vbr files) and work out the average.
As you can see from this example the average rate of change is 7.63GB or 7813.12MB
So let’s use a scenario as an example:
The line speed is 6Mb/s and we questimate that we will get 70% of the bandwidth…
Next download and install ReplicaCalc from here > ReplicaCalc (10196 downloads)
If you cannot perform a local backup/replication to ascertain the average rate of change then you could always use the RateOfChange RuleOfThumb or RCRT which states that overtime on average the rate of change will be ~10%. So if your source full snapshots equate to 1TB then the rate of change will 100Gb. Of course this is BS as every user has different results but it’s a good starting point if you have nothing else to reference.
Note this tool only gives you an approximation. Too many factors can change the actual outcome.
|Save & Optimise Virtual Disk Storage for FREE.
This article demonstrates a FREE way of saving/optimising Virtual Disk storage space using software which is freely available. Include is :1. How to report which disks are over-allocated using our very own free vdisk waste finder application from here > Vdisk Waste Finder (5364 downloads)
2. How to resize over-allocated vdisks using a free open source application called “gparted”
3. How to align the vdisk including system disks to a 64k start sector. This increases performance and reduces disk latency using a free open source application called “gparted”So to get started first of all download all the software by clicking on the application names above./Disclaimer: Virtualizeplanet will not be liable if anything was to go wrong whilst performing the following operations. Do at your own risk and we will not be responsible for data loss or down time./
How to report which disks are over-allocated.
Update on this post, watch how to do this found > here <
Firstly use Vdisk Waste Finder by pointing the application to your ESX server or vCenter server, providing credentials, specifying the percentage of free space you want to look for and then clicking go.
How to resize over-allocated vdisks.
Secondly Add a vdisk to the candidate VM of the new optimal size using the VI client.
Then resize the original drive to the same size as the newly add drive:
Click Picture to make larger
In the VI client back in the settings of VM remove the old drive.
How to align the vdisk including system disks to a 64k start sector.
The idea here is to make sure your partition starts on a sector number derivable by 64, so for example 64 or 128 or 256. This will increase your VM disk performance and reduce latency.
New update and “how to” video found >HERE<
Follow these steps:
parted will create a new primary partition from sector 63 to sector 127. That means the very next sector available is 128.
Your partition should now start on an optimized sector
But how do you find misaligned disks in the first place? Click >HERE < to find out
|Last Updated ( Mar 07, 2010 at 03:47 PM )|
A client told me today he thought he was having poor backup performance over a virtual network. But when he started debugging he noticed that it wasn’t just Backup that was the problem it was all network IO through a local vswitch. He started the conversation by asking me what I expect to see in network throughput between 2 VMs localised on the same vswitch. He informed me no matter what he tried in terms of using a vswitch with/without a pNIC and trying different types of vNIC he couldn’t push 240mbits/s. He asked him the obvious question which was “Is there anything else happening on the system that could be impacting net performance, like CPU overhead” and the answer was “no”.
So I decided to test it for myself.
As did my client I used the Netperf tool to test throughput between the 2 VMs. To use NetPerf you run:
C:\Netserver.exe on one VM
C:\Netclient.exe –H hostname (of the first system)
on the other VM.
After a few seconds you should get a result displayed in mbits/s
And just like my client I tested a vswitch with/without a pNIC and different types of vNIC. I also tested different hosts to get varied result. The problem is I saw results which I’d expect to see, and on average I saw speeds of 500mbits/s