Food for thought: Fixing an over-engineered environment
-
@dashrender said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
The VLAN2 networking would be done through connections to a Hyper-V private switch.
Why split keep VLAN 2?
FYI, multi-homing Windows machines can lead to pain. Not saying it's not possible, just can be painful. Not that you said you were multi homing anything.How will traffic get from the default VLAN onto VLAN 2, if the VMs are only on VLAN2 via a private Hyper-V switch?
I may have been unclear about this. There is no communication between the default VLAN and VLAN2. In the new setup, VLAN2 would go away. I'd configure two Virtual switches on the Hyper-V host. One external and one private. Each VM would have two vNIC, one connected to each virtual switch. Private switch would be for traffic between the VMs, and external switch for Internet access.
I haven't had a problem having multiple VMs sharing one NIC with our office server. Since the data center Hyper-V host has eight NICs, I could give each VM its own physical NIC if I wanted.
-
Ok so you do plan to multihome the VM. What are you hoping to gain by having this internal virtual switch?
-
@dashrender said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Yes, I have not mentioned backups yet. I am learning more so I can begin the brainstorm.
Where are your backups being stored?
You saidServer 3
- Runs Windows Server 2012 R2
- Yosemite backup;
- Storage: Two Intel S3500 300 GB SSDs in RAID 1 (24% of storage used)
Is your backup for everything fitting inside 300 GB? SSD in this case seems like overkill, but perhaps you need this?
No. Backup is stored on an external WD MyBook hard drive.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I'd configure two Virtual switches on the Hyper-V host. One external and one private. Each VM would have two vNIC, one connected to each virtual switch. Private switch would be for traffic between the VMs, and external switch for Internet access.
This seems unnecessarily complex for your environment. Any reason for doing this and not just a single virtual switch?
-
@dashrender said in Food for thought: Fixing an over-engineered environment:
Ok so you do plan to multihome the VM. What are you hoping to gain by having this internal virtual switch?
The original idea (which is likely flawed) of the network was to separate server-to-server traffic from server-to-Internet traffic. I believe the purpose of this was keep the server-to-server pipe free of the Internet traffic to prevent bottlenecks. However, I don't think this issue is really an issue (see images below). Creating the private virtual switch preserves this architecture, and I would assume data transfer would be faster over the private virtual switch rather than through the physical switch.
We also teamed two 1 GB NICs on each server to connect that internal VLAN to have more bandwidth. Each server has its host file configured to where the IPs of the other servers resolve to the internal subnet to make sure the traffic used the correct NIC.
SQL Server Network Traffic
Internal = Teamed GB NICs on VLAN2. External = single GB NIC on VLAN1
IIS server traffic is about the same. Three month average for the Internal team is 7.4 Mb/s TX and 1.69 Mb/s RX. The external NIC is 2.34 Mb/s TX and 863 Kb/s RX
REDIS server (that has postfix VM) has almost no traffic on the external NIC, and a three month average of 726 Kb/s TX and 10.5 MB/s RX on the Internal team.
Clearly, none of this is approaching saturation even for a 100 Mbps NIC, so perhaps the only thing gained from separating the traffic is extra complexity.
-
@coliver said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I'd configure two Virtual switches on the Hyper-V host. One external and one private. Each VM would have two vNIC, one connected to each virtual switch. Private switch would be for traffic between the VMs, and external switch for Internet access.
This seems unnecessarily complex for your environment. Any reason for doing this and not just a single virtual switch?
Ha! You beat me to the conclusion.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Creating the private virtual switch preserves this architecture, and I would assume data transfer would be faster over the private virtual switch rather than through the physical switch.
This assumes that VM-to-VM traffic leaves the virtual switch to begin with. IIRC none of the VM-to-VM traffice would be going to your physical switch. The virtual switch would be handling all of that traffic.
-
@coliver said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Creating the private virtual switch preserves this architecture, and I would assume data transfer would be faster over the private virtual switch rather than through the physical switch.
This assumes that VM-to-VM traffic leaves the virtual switch to begin with. IIRC none of the VM-to-VM traffice would be going to your physical switch. The virtual switch would be handling all of that traffic.
That's correct. Right now, nothing is virtualized, so each physical server has two teamed NICs sending traffic to our physical switch on VLAN2 as the Internal network, with another NIC sending traffic on the default VLAN as the External network.
Since my thought is to turn everything into a VM, it would be better performing to create a virtual private switch just for that VM-to-VM traffic rather than configure something that still utilizes the physical switch for such traffic. However, from what I'm seeing it doesn't look like separating that traffic onto its own private switch is necessary.
-
@coliver said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I'd configure two Virtual switches on the Hyper-V host. One external and one private. Each VM would have two vNIC, one connected to each virtual switch. Private switch would be for traffic between the VMs, and external switch for Internet access.
This seems unnecessarily complex for your environment. Any reason for doing this and not just a single virtual switch?
I agree. What’s the benefit here?
-
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@coliver said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I'd configure two Virtual switches on the Hyper-V host. One external and one private. Each VM would have two vNIC, one connected to each virtual switch. Private switch would be for traffic between the VMs, and external switch for Internet access.
This seems unnecessarily complex for your environment. Any reason for doing this and not just a single virtual switch?
I agree. What’s the benefit here?
From the data that New Relic shows me, it looks like there isn't any. I guess I could make an argument that the SQL Server VM and the REDIS VM shouldn't have Internet access. The problem with that is two fold.
- I'd add the complexity of having WSUS or something to be able to feed those VMs Windows updates.
- It seems like having a way to RDP into those machines would be overly complex.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Since my thought is to turn everything into a VM, it would be better performing to create a virtual private switch just for that VM-to-VM traffic rather than configure something that still utilizes the physical switch for such traffic. However, from what I'm seeing it doesn't look like separating that traffic onto its own private switch is necessary.
I'm confused as to how you would see better performance? You're going to have more then one host correct? Unless you are planning on setting up an independent physical switch for host-to-host/vm-to-vm communication then everything would be going over the physical switch regardless. VLANs aren't for performance purposes they are for security purposes.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Since my thought is to turn everything into a VM, it would be better performing to create a virtual private switch just for that VM-to-VM traffic rather than configure something that still utilizes the physical switch for such traffic. However, from what I'm seeing it doesn't look like separating that traffic onto its own private switch is necessary.
The idea might have some credibility in the real world, but in a single host, where the traffic is all on vswitches, this won't really make any difference.
Each VM with only one a single vswitch connection, all inter VM traffic will stay inside the hypervisor, never touching the physical switches. You team several 1 GB or upgrade to a 10GB NIC in the server (and a 10 GB port on the switch) and you shouldn't see that be a bottle neck at all. -
@coliver
Right now, I'm planning on one host with multiple VMs. So if I had this separate, internal network, methinks performance would be better on a virtual private switch, rather than using virtual external switches bound to a physical NIC that is a part of a separate VLAN on the physical switch.On performance, you're right about VLANs, they're designed for security. I guess you could argue you'd reducing potential broadcast traffic, but in this situation that wouldn't matter, as the number of devices is the same. It looks more and more like the separate-network-for-server-to-server communication is unnecessary.
@Dashrender
You're right. The only time VM traffic would be going over a 1 GB link would be when that traffic has to travel over the physical NIC to the physical switch. Even if the virtual switch was an external switch, the VM to VM traffic would be going over the 10 GB virtual switch link. -
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Right now, I'm planning on one host with multiple VMs. So if I had this separate, internal network, methinks performance would be better on a virtual private switch, rather than using virtual external switches bound to a physical NIC that is a part of a separate VLAN on the physical switch.
Probably not. But you're talking yourself out of it now so I don't need to say anything else.
-
@coliver said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Right now, I'm planning on one host with multiple VMs. So if I had this separate, internal network, methinks performance would be better on a virtual private switch, rather than using virtual external switches bound to a physical NIC that is a part of a separate VLAN on the physical switch.
Probably not. But you're talking yourself out of it now so I don't need to say anything else.
Yeah, during this thought process, I'll likely be talking myself out of most things that would be just a virtualized version of current architecture. -
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@coliver said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Right now, I'm planning on one host with multiple VMs. So if I had this separate, internal network, methinks performance would be better on a virtual private switch, rather than using virtual external switches bound to a physical NIC that is a part of a separate VLAN on the physical switch.
Probably not. But you're talking yourself out of it now so I don't need to say anything else.
Yeah, during this thought process, I'll likely be talking myself out of most things that would be just a virtualized version of current architecture.Definitely a hard thing to get over at times.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@coliver said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Right now, I'm planning on one host with multiple VMs. So if I had this separate, internal network, methinks performance would be better on a virtual private switch, rather than using virtual external switches bound to a physical NIC that is a part of a separate VLAN on the physical switch.
Probably not. But you're talking yourself out of it now so I don't need to say anything else.
Yeah, during this thought process, I'll likely be talking myself out of most things that would be just a virtualized version of current architecture.So green field it. Ignore current infrastructure for a bit. How would you make this work in an ideal environment. Then look at where what you have now differs from that ideal. Are those differences necessary? Would moving them toward ideal adversely effect users?
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@coliver
Right now, I'm planning on one host with multiple VMs. So if I had this separate, internal network, methinks performance would be better on a virtual private switch, rather than using virtual external switches bound to a physical NIC that is a part of a separate VLAN on the physical switch.If the VMs are on the same host no need to give them internal and external virtual NICs. They will communicate over the external virtual switch, but the traffic wont go to the physical NIC/out to the LAN.
You only want internal switch between VMs where they are only supposed to talk with each other/not be on a LAN.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
On performance, you're right about VLANs, they're designed for security. I guess you could argue you'd reducing potential broadcast traffic, but in this situation that wouldn't matter, as the number of devices is the same. It looks more and more like the separate-network-for-server-to-server communication is unnecessary.
I didn't think they were for security...
I thought VLANs were purely for segregation of traffic to make quality of service/planning better. Yeah sure, something on VLAN1 wont interact with VLAN2... but its the same switch/hardware/cables. So I presume if I can get access to that kit with Wireshark or something id be able to get the traffic regardless of VLANs, and the fact they are VLANs wouldn't matter... Could be wrong here though (probably am)...
-
@jimmy9008 said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
On performance, you're right about VLANs, they're designed for security. I guess you could argue you'd reducing potential broadcast traffic, but in this situation that wouldn't matter, as the number of devices is the same. It looks more and more like the separate-network-for-server-to-server communication is unnecessary.
I didn't think they were for security...
I thought VLANs were purely for segregation of traffic to make quality of service/planning better.
No that's the myth. They actually make those things worse. They make planning harder and confuse people about QoS. They add overhead and bottlenecks so you have to plan more and do more QoS just ot overcome the VLAN problems. VLANs are for security in some limited cases and for management on a massive scale.
