One best practice is to assign either a dedicated gigabit Ethernet NIC or TCP offload adapter (ToE adapter) in each server to handle iSCSI traffic — in other words, don’t share your user-facing network connection for storage traffic. If you’ve created a separate physical network or VLAN for storage traffic, assign this adapter an IP address that works on the storage network. By placing storage traffic on its own network that is routed separately from the main network, you increase the overall security of your storage infrastructure and simplify the overall configuration.
Fixing Tanzu Kubernetes Pod to External Services Connectivity Issues with NSX-T Last month I got a call from a customer who was pulling their hair out over a networking issue. They had just deployed VMware Tanzu Kubernetes Grid on their vSphere with Tanzu environment, everything looked good in the dashboards, all pods were running, but their applications inside the pods could not reach external databases running on traditional VMs in the same datacenter. The frustrating part was that some pods could reach external services perfectly fine, while others would just timeout. There was no clear pattern. Let me tell you how we figured this out and fixed it. The Initial Problem Here is what the customer setup looked like: vSphere 8.0 with Tanzu enabled NSX-T 4.1.2 for networking Three Tanzu Kubernetes clusters running different microservices applications External PostgreSQL database running on traditional VMs (non-Kubernetes) External API services running on another se...