- when defining the replication partner, the SAN doesn't 'test' if your information is right, so if you defined the partner incorrectly, you wouldn't know till you try to replicate an actual volume
- when defining a replication partner, the connection is case sensitive for the group name
- just to ensure the 2nd SAN is set up, you could add that group IP to the iSCSI initiator on one of your ESX boxes, create a dummy volume and verify that the ESX box can see the volume (don't need to format it or so, just verify that it's visible under the storage adapters)
Case-sensitiv group name was the thing. But I cant understand why it is case-senstive and could not find this documented anywhere. I have been both googling and reading the documentation for the last couple of days without getting a hint about this.
One other thing, the documentation says that if you put a layer 3 address on each network modules interface, the network performance of the SAN would improve. As the technique used is Layer 2 multicasting I cant see how a layer 3 address on each interface would improve the network?
Any link to a network configuration document would have been nie:-)
Most people do replication between 2 different sites/buildings. When using a network that's that spread out, you don't want both locations to use the same subnet. So, if you are using 2 different subnets, you need a route between them so they can reach eachother. This is where the layer 3 address comes in.
If you have no intentions to move one unit to another site (especially if you're going to keep it in the same serverroom), why bother with replication? Unless you're just using it to learn about replication.
The SAN's will be on the same network using dedicated fibre cables between the sites/switches. I want the best performance, so if a layer2 mechanism is used within a SAN or replication between 2 SAN's, it seems for me to be the best option.
Dev Mgr
4 Operator
•
9.3K Posts
1
September 17th, 2010 08:00
A few things:
- when defining the replication partner, the SAN doesn't 'test' if your information is right, so if you defined the partner incorrectly, you wouldn't know till you try to replicate an actual volume
- when defining a replication partner, the connection is case sensitive for the group name
- just to ensure the 2nd SAN is set up, you could add that group IP to the iSCSI initiator on one of your ESX boxes, create a dummy volume and verify that the ESX box can see the volume (don't need to format it or so, just verify that it's visible under the storage adapters)
jepp
6 Posts
0
September 20th, 2010 00:00
Thx a lot!
Case-sensitiv group name was the thing. But I cant understand why it is case-senstive and could not find this documented anywhere. I have been both googling and reading the documentation for the last couple of days without getting a hint about this.
One other thing, the documentation says that if you put a layer 3 address on each network modules interface, the network performance of the SAN would improve. As the technique used is Layer 2 multicasting I cant see how a layer 3 address on each interface would improve the network?
Any link to a network configuration document would have been nie:-)
\\Jepp
Dev Mgr
4 Operator
•
9.3K Posts
0
September 20th, 2010 07:00
Most people do replication between 2 different sites/buildings. When using a network that's that spread out, you don't want both locations to use the same subnet. So, if you are using 2 different subnets, you need a route between them so they can reach eachother. This is where the layer 3 address comes in.
If you have no intentions to move one unit to another site (especially if you're going to keep it in the same serverroom), why bother with replication? Unless you're just using it to learn about replication.
jepp
6 Posts
0
September 22nd, 2010 01:00
The SAN's will be on the same network using dedicated fibre cables between the sites/switches. I want the best performance, so if a layer2 mechanism is used within a SAN or replication between 2 SAN's, it seems for me to be the best option.
``Jepp