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.
-
@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.
-
@jimmy9008 said in Food for thought: Fixing an over-engineered environment:
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)...
That's subnets that you are thinking of. If you can do that with a VLAN, it's not a VLAN
The definition of a VLAN means that that can't be done. -
Okay, I've not read everything but starting from the top...
Networking - VLANs are gone. You describe very clearly in the OP that they serve no purpose, don't talk about them again. Gone. Done. Over. One Big Flat Network, OBFN.
Servers - Definitely no need for more than one. Going down to just one will significantly improve your performance and your reliability. Right now your apps depend on the separate database server which depends on your SAN. That's an inverted pyramid with another tier. So instead of the normal three tiers of risk, you have five! Collapsing that down to one will make you so much more reliable. Hyper-V is fine. So is KVM.
Storage - This is easy, local disks. Either all SSD or one SSD pool and one spinner pool. That's all.
-
REDIS should be on Linux, REDIS on Windows is crazy. It's expensive and slow.
-
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
REDIS should be on Linux, REDIS on Windows is crazy. It's expensive and slow.
I just finished reading a little on REDIS yesterday, and when I asked myself why we're running it on Windows, the answer came to me. Previous and most of current regime (I'm the exception) = if there's a way to do X with Microsoft, use Microsoft.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
REDIS should be on Linux, REDIS on Windows is crazy. It's expensive and slow.
I just finished reading a little on REDIS yesterday, and when I asked myself why we're running it on Windows, the answer came to me. Previous and most of current regime (I'm the exception) = if there's a way to do X with Microsoft, use Microsoft.
sigh
I'd have the same reaction to anyone that just defaulted to = if there's a way to do X with CentoOS, use CentOS mentality.
-
@travisdh1 said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
REDIS should be on Linux, REDIS on Windows is crazy. It's expensive and slow.
I just finished reading a little on REDIS yesterday, and when I asked myself why we're running it on Windows, the answer came to me. Previous and most of current regime (I'm the exception) = if there's a way to do X with Microsoft, use Microsoft.
sigh
I'd have the same reaction to anyone that just defaulted to = if there's a way to do X with CentoOS, use CentOS mentality.
Except one is saving the company money the other is costing them? Not sure if that's a direct corollary.
