Network latency is an important factor when designing a VMware Cloud Foundation (VCF) Fleet and to assist VCF architects in understanding the various latency maximums, we have just published a new VCF Fleet Latency Network Diagram, which is available under the Network Diagrams on the VMware Ports & Protocols website.
While these latency represent the upper bound for component to component functionality, it is also important to understand that latency can have different types of impact based on the type of traffic: control plane (UI/API) versus data plane (binary download…
Network latency is an important factor when designing a VMware Cloud Foundation (VCF) Fleet and to assist VCF architects in understanding the various latency maximums, we have just published a new VCF Fleet Latency Network Diagram, which is available under the Network Diagrams on the VMware Ports & Protocols website.
While these latency represent the upper bound for component to component functionality, it is also important to understand that latency can have different types of impact based on the type of traffic: control plane (UI/API) versus data plane (binary download/uploads).
For example, most of the UI/API invocations are asynchronous, meaning the requests will be recieved by a component but it may be slow to respond with higher latency. For data plane traffic, throughput is typically reduced and longer transfer times maybe observed with higher latency. Luckily, for Lifecycle management operations, it is fairly common to stage the binaries prior to performing the lifecycle operation, so while transfer times may take longer, we can mitigate any impact of the actual lifecycle operation.
Note: One thing I would like to point out in the diagram is that VCF Operations Collector expects <=50ms to vCenter Server, NSX Manager and SDDC Manager. In the scenarios where you might have a Workload Domain vCenter Server (Brownfield Import) that is a bit further away from the primary VCF Operations Collector within VCF Instance, we can mitigate that by deploying an additional VCF Operations Collector that is local to that Workload Domain and thus ensuring the <=50ms requirement while benefiting from the <=300ms back to VCF Operations.
As the first version of the VCF Fleet Latency diagram, only the primary VCF components within a VCF Fleet has been included in this initial diagram. Additional VCF components will be incorporated into future iterations based on your feedback. If there are things you would like to see in future updates, you can leave feedback directly on the Broadcom page or feel free to leave a comment below and I will make sure it reaches the PM.