All TKB Articles in Help & Resources

When using the VMXNET3 driver on ESXi 4.x, 5.x, 6.x, you see significant packet loss during periods of very high traffic bursts Cause This issue occurs when packets are dropped during high traffic bursts. This can occur due to a lack of receive and transmit buffer space or when receive traffic which is speed-constrained. For example, with a traffic filter. To resolve this issue, ensure that there is no traffic filtering occurring (for example, with a mail filter). After eliminating this possibility, slowly increase the number of buffers in the guest operating system. To reduce burst traffic drops in Windows Buffer Settings: Click Start > Control Panel > Device Manager. Right-click vmxnet3 and click Properties. Click the Advanced tab. Click Small Rx Buffers and increase the value. The maximum value is 8192. Click Rx Ring #1 Size and increase the value. The maximum value is 4096 Note:- These changes will happen on the fly, so no reboot is required. However, any application sensitive to TCP session disruption can likely fail and have to be restarted. This applies to RDP, so it is better to do this work in a console window. This issue is seen in the Windows guest operating system with a VMXNET3 vNIC. It can occur with versions besides 2008 R2. It is important to increase the value of Small Rx Buffers and Rx Ring #1 gradually to avoid drastically increasing the memory overhead on the host and possibly causing performance issues if resources are close to capacity. If this issue occurs on only 2-3 virtual machines, set the value of Small Rx Buffers and Rx Ring #1 to the maximum value. Monitor virtual machine performance to see if this resolves the issue. The Small Rx Buffers and Rx Ring #1 variables affect non-jumbo frame traffic only on the adapter.

Dear readers Welcome to this new blog post talking about static routing with the NSX-T Tier-0 Gateway. The majority of our customers are using BGP for the Tier-0 Gateway to Top of Rack (ToR) switches connectivity to exchange IP prefixes. For those customers who prefer static routing, this blog post talks about the two design options. Design Option 1: Static Routing using SVI as Next Hop with NSX-T Edge Node in Active/Active Mode to support ECMP for North/South Design Option 2: Static Routing using SVI as Next Hop with NSX-T Edge Node in Active/Standby Mode using HA VIP I have the impression that the second design option with a Tier-0 Gateway with two NSX-T Edge Node in Active/Standby mode using HA VIP is widely known, but the first option with NSX-T Edge Node in Active/Active mode leveraging ECMP with static routing is pretty unknown. This first option is for example also a valid Enterprise PKS (new name is Tanzu Kubernetes Grid Integration - TKGI) design option (with shared Tier-1 Gateway) or can be used with vSphere 7 with Kubernetes (Project Pacific) as well where BGP is not allowed nor preferred. I am sure the reader is aware, that Tier-0 Gateway in Active/Active mode cannot be enabled for stateful services (e.g. Edge firewall). Before we start to configure these two different design options, we need to describe the overall lab topology, the physical and logical setup along with the NSX-T Edge Node setup including the NSX-T Edge Node main installation steps. For both options we will configure only a single N-VDS on the NSX-T Edge Node. This is not a requirement, but it is considered a pretty simple design option. The other popular design options consist of typically three embedded N-VDS on the NSX-T Edge Node for design option 1 and two embedded N-VDS on the NSX-T Edge Node for design option 2. Logical Lab Topology The lab setup is pretty simple. For an easy comparison between those two options, I have configured both design options in parallel. The most relevant part for this blog post is between the two Tier-0 Gateways and the two ToR switches acting as Layer 3 Leaf switches. The configuration and design for the Tier-1 Gateway and the compute vSphere cluster hosting the eight workload Ubuntu VMs is identially for both design options. There is only a single Tier-1 Gateway per Tier-0 Gateway configured, each with two overlay segments. The eight workload Ubuntu VMs are installed on different Compute vSphere cluster called NY-CLUSTER-COMPUTE1 with only two ESXi hosts and are evenly distributed on the two ESXi hosts. Those two compute ESXi hosts are prepared with NSX-T and have only a single overlay Transport Zone configured. The four NSX-T Edge Node VMs are running on another vSphere cluster, called NY-CLUSTER-EDGE1. This vSphere cluster has again only two ESXi hosts. A third vSphere cluster called NY-CLUSTER-MGMT is used for the management component, like vCenter and the NSX-T managers. Details about the compute and management vSphere clusters are not relevant for this blog post and hence are deliberately omitted. The diagram below shows the NSX-T logical topology, the most relevant vSphere objects and underneath the NSX-T overlay and VLAN segments (for the NSX-T Edge Node North/South connectivity. Physical Setup Lets have first a look at physical setup used for our four NSX-T VM-based Edge Nodes. Understanding the physical is no less important than the logical setup. Two Nexus 3048 ToR switches configured as Layer 3 Leaf switches are used. They have a Layer 3 connection towards a single spine (not shown) and two Layer 2 trunks combined into a single portchannel with LACP between the two ToR switches. Two ESXi hosts (ny-esx50a and ny-esx51a) with 4 pNICs in total assigned to two different virtual Distributed Switches (vDS). Please note, the Nexus 3048 switches are not configured with Cisco vPC, even this would also be a valid option. The relevant physical links for the NSX-T Edge Nodes connectivity are the four green links only connected to vDS2. Those two ESXi hosts (ny-esx50a and ny-esx51a) are NOT prepared. The two ESXi hosts belong to a single vSphere Cluster exclusively used for NSX-T Edge Node VMs. There are a few good reasons NOT to prepare those ESXi hosts with NSX-T where you host only NSX-T Edge Node VMs: It is not required Better NSX-T upgrade-ability (you don't need to evacuate the NSX-T VM-based Edge Nodes during host NSX-T software upgrade with vMotion to enter maintenance mode; every vMotion of the NSX-T VM-based Edge Node will cause a short unnecessary data plane glitch) Shorter NSX-T upgrade cycles (for every NSX-T upgrade you only need to upgrade the ESXi hosts which are used for the payload VMs and only the NSX-T VM-based Edge Nodes, but not the ESXi hosts where you have your Edge Nodes deployed vSphere HA can be turned off (do we want to move a highly loaded packet forwarding node like an NSX-T Edge Node with vMotion in a host vSphere HA event? No I don't think so - as the routing HA model react in a failure event faster) Simplified DRS settings (do we want to move an NSX-T VM-based Edge Node with vMotion to balance the resources?) Typically a resource pool is not required We should never underestimate how important smooth upgrade cycles are. Upgrade cycles are time consuming events and are typically required multiple times per year. To have the ESXi host NOT prepared for NSX-T is considered best practice and should always be deployed in any NSX-T deployments which can afford a dedicated vSphere Cluster only for NSX-T VM-based Edge Nodes. Install NSX-T on ESXi hosts where you have deployed your NSX-T VM-based Edge Nodes (called collapsed design) is valid too and appropriate for customers who have a low number of ESXi hosts to keep the CAPEX costs low. ESXi Host vSphere Networking The first virtual Distributed Switch (vDS1) is used for the host vmkernel networking only. The typical vmkernel interfaces are attached to three different port groups. The second virtual Distributed Switch (vDS2) is used for the NSX-T VM-based Edge Node networking only. All virtual Distributed Switches port groups are tagged with the appropriate VLAN id, with the exception of the three uplink trunk port groups (more details later). Both virtual Distributed Switches are configured for MTU 9000 bytes and I am using a different Geneve Tunnel End Point (TEP) VLAN for the Compute ESXi hosts (VLAN 150 for ny-esx70a and ny-esx71a) and for the two NSX-T VM-based Edge Node (VLAN 151) running on the ESXi hosts (ny-esx50a and ny-esx51a). In such a setup this is not a requirement, but helps to distribute the BUM traffic replication effort leveraging the hierarchical 2-Tier replication mode. The "dummy" port group is used to connect the unused NSX-T Edge Node fast path interface (fp-ethX); the attachment to a dummy port group is done to avoid that NSX-T reports it as interface admin status down. Table 1 - vDS Setup Overview Name Diagram vDS Name Physical Interfaces Port Groups vDS1 NY-vDS-ESX5x-EDGE1 vmnic0 and vmnic1 NY-vDS-PG-ESX5x-EDGE1-VMK0-Mgmt50 NY-vDS-PG-ESX5x-EDGE1-VMK1-vMotion51 NY-vDS-PG-ESX5x-EDGE1-VMK2-ipStorage52 vDS2 NY-vDS-ESX5x-EDGE2 vmnic2 and vmnic3 NY-vDS-PG-ESX5x-EDGE2-EDGE-Mgmt60 (Uplink 1 active, Uplink 2 standby) NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkA (Uplink 1 active, Uplink 2 unused) NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkB (Uplink 1 unused, Uplink 2 active) Ny-vDS-PG-ESX5x-EDGE2-EDGE-TrunkC (Uplink 1 active, Uplink 2 active) NY-vDS-PG-ESX5x-EDGE2-Dummy999 (Uplink 1 and Uplink 2 are unused) The combined diagram below shows the most relevant NY-vDS-ESX5x-EDGE2 port group settings regarding VLAN trunking and Teaming and Failover. Logical VLAN Setup The ToR switches are configured with those relevant four VLANs (60, 151,160 and 161) for the NSX-T Edge Nodes and the associated Switched Virtual Interfaces (SVI). The VLANs 151, 160 and 161 (VLAN 161 is not used in design option 2) are carried over the three vDS trunk port groups (NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkA, NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkB and NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkC). The SVI on the Nexus 3048 for Edge Management (VLAN 60) and for the Edge Node TEP (VLAN 151) are configured with HSRPv2 with a VIP of .254. The two SVIs on the Nexus 3048 for the Uplink VLAN (160 and 161) are configured without HSRP. VLAN999 as the dummy VLAN does not exists on the ToR switches. The Tier-1 Gateway is not shown in the diagrams below. Please note the dotted line to SVI161 respective SVI160 indicates that the VLAN/SVI configuration on the ToR switch exists, but is not used for the static routing when using Active/Active ECMP with static routing (design option 1). And the dotted line to SVI161 in design option 2 indicates that the VLAN/SVI configuration on the ToR switches exists, but is not used for the static routing when using Active/Standby with HA VIP with static routing. More details about the static routing is shown in a later step. NSX-T Edge Node Deployment The NSX-T Edge Node deployment option with the single Edge Node N-VDS is simple and has been discussed in one of my other blog posts. In this lab exercise I have done an NSX-T Edge Node ova installation, followed by the "join" command followed by the final step of the NSX-T Edge Transport Node configuration. The NSX-T UI installation option is valid as well, but my personal preference is the ova deployment option. The most relevant step for such a NSX-T Edge Node setup is the correct place of the dot1q tagging and the correct mapping of the NSX-T Edge Node interfaces to the virtual Distributed Switches (vDS2) trunk port groups (A & B for option 1 and C for option 2) as shown in the diagrams below. The diagram below shows the NSX-T Edge Node overall setup and the network selection for the NSX-T Edge Node 20 & 21 during the ova deployment for the design option 1: The diagram below shows the NSX-T Edge Node overall setup and the network selection for the NSX-T Edge Node 22 & 23 during the ova deployment for the design option 2: After the successful ova deployment the "join" command must be used to connect the management plane of the NSX-T Edge Nodes to the NSX-T managers. The "join" command requires the NSX-T manager thumbprint. Jump with SSH to the first NSX-T manager and read the API thumbprint. Jump via SSH to every ova deployed NSX-T Edge Node and execute the "join" command. The two steps are shown the in the table below: Table 2 - NSX-T Edge Node "join" to the NSX-T Managers Step Command Example Device Comments Read API Thumbprint ny-nsxt-manager-21> get certificate api thumbprint ea90e8cc7adb6d66994a9ecc0a930ad4bfd1d09f668a3857e252ee8f74ba1eb4 first NSX-T manager N/A Join the NSX-T Manager for each NSX-T Edge Node ny-nsxt-edge-node-20> join management-plane ny-nsxt-manager-21.corp.local thumbprint ea90e8cc7adb6d66994a9ecc0a930ad4bfd1d09f668a3857e252ee8f74ba1eb4 username admin Password for API user: Node successfully registered as Fabric Node: 437e2972-bc40-11ea-b89c-005056970bf2 ny-nsxt-edge-node-20> --- do the same for all other NSX-T Edge Nodes --- on all previous deployed NSX-T Edge Node through ova NSX-T will sync the configuration with the two other NSX-T managers Do not join using the NSX-T manager VIP FQDN/IP The resulting UI after the "join" command is shown below. The configuration state must be "Configure NSX". NSX-T Edge Transport Node Configuration Before we can start with the NSX-T Edge Transport Node configuration, we need to be sure, that the Uplink Profiles are ready. The two design options require two different Uplink Profiles. The two diagrams below shows the two different Uplink Profiles for the NSX-T Edge Transport Nodes: The Uplink Profile "NY-EDGE-UPLINK-PROFILE-SRC-ID-TEP-VLAN151" is used for design option 1 and is required for Multi-TEP with the teaming policy "LOADBALANCE_SRCID" with two Active Uplinks (EDGE-UPLINK01 and EDGE-UPLINK02). Two additional named teaming policies are configured for a proper ECMP dataplane forwarding; please see blog post "Single NSX-T Edge Node N-VDS with correct VLAN pinning" for more details. I am using the same named teaming configuration for design option 1 as in the other blog post where I have used BGP instead of static routing. As mentioned already, the dot1q tagging (Transport VLAN = 151) for the two TEP interfaces is required as part of this Uplink Profile configuration. The Uplink Profile "NY-EDGE-UPLINK-PROFILE-FAILOVER-TEP-VLAN151" is used for design option 2 and requires the teaming policy "FAILOVER_ORDER" with only a single Active Uplink (EDGE-UPLINK01). Named teaming policies are not required. Again the dot1q tagging for the single TEP interface (Transport VLAN = 151) is required as part of this Uplink Profile configuration. The NSX-T Edge Transport Node configuration itself is straightforward and is shown in the two diagrams below for a single NSX-T Edge Transport Node per design option. NSX-T Edge Transport Node 20 & 21 (design option 1) are using the previous configured Uplink Profile "NY-EDGE-UPLINK-PROFILE-SRC-ID-TEP-VLAN151". Two static TEP IP addresses are configured and the two Uplinks (EDGE-UPLINK01 & EDGE-UPLINK02) are mapped to the fast path interfaces (fp-eth0 & fp-eth1). NSX-T Edge Transport Node 22 & 23 (design option 2) are using the previous configured Uplink Profile "NY-EDGE-UPLINK-PROFILE-FAILOVER-TEP-VLAN151". A single static TEP IP address is configured and the single Uplink (EDGE-UPLINK01) is mapped to the fast path interface (fp-eth0). Please note, the required configuration of the two NSX-T Transport Zones and the single N-VDS switch is not shown. The NSX-T Edge Transport Node ny-nsxt-edge-node-20 and ny-nsxt-edge-node-21 are assigned to the NSX-T Edge cluster NY-NSXT-EDGE-CLUSTER01 and the NSX-T Edge Transport Node ny-nsxt-edge-node-22 and ny-nsxt-edge-node-22 are assigned to the NSX-T Edge cluster NY-NSXT-EDGE-CLUSTER02. This NSX-T Edge cluster configuration is also not shown. NSX-T Tier-0 Gateway Configuration The base NSX-T Tier-0 Gateway configuration is straightforward and is shown in the two diagrams below. The Tier-0 Gateway NY-T0-GATEWAY-01 (design option 1) is configured in Active/Active mode along with the association with the NSX-T Edge Cluster NY-NSXT-EDGE-CLUSTER01. The Tier-0 Gateway NY-T0-GATEWAY-02 (design option 2) is configured in Active/Standby mode along with the association with the NSX-T Edge Cluster NY-NSXT-EDGE-CLUSTER02. In this example preemptive is selected and the first NSX-T Edge Transport Node (ny-nsxt-edge-node-22) is the preferred Edge Transport Node (the active node when both nodes are up and running). The next step of Tier-0 Gateway configuration is about the Layer 3 interfaces (LIF) for the northbound connectivity towards the ToR switches. The next two diagrams show the IP topologies including the ToR switches IP configuration along the resulting NSX-T Tier-0 Gateway Layer 3 interface configuration for the design option 1 (A/A ECMP). The next diagrams show the IP topology including the ToR switches IP configuration along the resulting NSX-T Tier-0 Gateway interface configuration for the design option 2 (A/S HA VIP). The HA VIP configuration requires that both NSX-T Edge Transport Node interfaces belong to the same Layer 2 segment. Here I am using the previous configured Layer 3 interfaces (LIF); both belong to the same VLAN segment 160 (NY-T0-VLAN-SEGMENT-160). All the previous steps are probably known by the majority of the readers. However, the next step is about the static routing configuration; these steps highlights the relevant configurations to archive ECMP with two NSX-T Edge Transport Node in Active/Active mode. Design Option 1 Static Routing (A/A ECMP) The first step in design option 1 is the Tier-0 static route configuration for northbound traffic. The most common way is to configure default routes northbound. Two default routes each with a different Next Hop (172.16.160.254 and 172.16.161.254) are configured on the NY-T0-GATEWAY-01. This is the first step to achieve ECMP for northbound traffic towards the ToR switches. The diagram below shows the corresponding NSX-T Tier-0 Gateway static routing configuration. Please keep in mind, that at the NSX-T Edge Transport Node level, each Edge Transport Node will have two default route entries. This is shown in the table below. The difference between the logical construct configuration (Tier-0 Gateway) and the "physical" construct configuration (the Edge Transport Nodes) might already be known, as we have the same behavior with BGP. This approach limits configuration errors. With BGP we typically configure only two BGP peers towards the two ToR switches, but each NSX-T Edge Transport Nodes gets two BGP session realized. The diagram below shows the setup with the two default routes (in black) northbound. Please note, the configuration steps how to configure the Tier-1 Gateway (NY-T1-GATEWAY-GREEN) and how to connect it to the Tier-0 Gateway is not shown. Table 3 - NSX-T Edge Transport Node Routing Table for Design Option 1 (A/A ECMP) ny-nsxt-edge-node-20 (Service Router) ny-nsxt-edge-node-21 (Service Router) ny-nsxt-edge-node-20(tier0_sr)> get route 0.0.0.0/0 Flags: t0c - Tier0-Connected, t0s - Tier0-Static, b - BGP, t0n - Tier0-NAT, t1s - Tier1-Static, t1c - Tier1-Connected, t1n: Tier1-NAT, t1l: Tier1-LB VIP, t1ls: Tier1-LB SNAT, t1d: Tier1-DNS FORWARDER, t1ipsec: Tier1-IPSec, isr: Inter-SR, > - selected route, * - FIB route Total number of routes: 1 t0s> * 0.0.0.0/0 [1/0] via 172.16.160.254, uplink-307, 03:29:43 t0s> * 0.0.0.0/0 [1/0] via 172.16.161.254, uplink-309, 03:29:43 ny-nsxt-edge-node-20(tier0_sr)> ny-nsxt-edge-node-21(tier0_sr)> get route 0.0.0.0/0 Flags: t0c - Tier0-Connected, t0s - Tier0-Static, b - BGP, t0n - Tier0-NAT, t1s - Tier1-Static, t1c - Tier1-Connected, t1n: Tier1-NAT, t1l: Tier1-LB VIP, t1ls: Tier1-LB SNAT, t1d: Tier1-DNS FORWARDER, t1ipsec: Tier1-IPSec, isr: Inter-SR, > - selected route, * - FIB route Total number of routes: 1 t0s> * 0.0.0.0/0 [1/0] via 172.16.160.254, uplink-292, 03:30:42 t0s> * 0.0.0.0/0 [1/0] via 172.16.161.254, uplink-306, 03:30:42 ny-nsxt-edge-node-21(tier0_sr)> The second step is to configure static routing southbound from the ToR switches towards NSX-T Edge Transport Node. This step is required to achieve ECMP for southbound traffic. Each ToR switch is configured with four static routes in total to forward traffic to the destination overlay networks within NSX-T. We could easily see that each NSX-T Edge Transport Node is used twice as Next Hop for the static route entries. Table 4 - Nexus ToR Switches Static Routing Configuration and Resulting Routing Table for Design Option 1 (A/A ECMP) NY-N3K-LEAF-10 NY-N3K-LEAF-11 ip route 172.16.240.0/24 Vlan160 172.16.160.20 ip route 172.16.240.0/24 Vlan160 172.16.160.21 ip route 172.16.241.0/24 Vlan160 172.16.160.20 ip route 172.16.241.0/24 Vlan160 172.16.160.21 ip route 172.16.240.0/24 Vlan161 172.16.161.20 ip route 172.16.240.0/24 Vlan161 172.16.161.21 ip route 172.16.241.0/24 Vlan161 172.16.161.20 ip route 172.16.241.0/24 Vlan161 172.16.161.21 NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 03:26:44, static     *via 172.16.160.21, Vlan160, [1/0], 03:26:58, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 03:26:44, static     *via 172.16.160.21, Vlan160, [1/0], 03:26:58, static ---snip--- NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 03:27:39, static     *via 172.16.161.21, Vlan161, [1/0], 03:27:51, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 03:27:39, static     *via 172.16.161.21, Vlan161, [1/0], 03:27:51, static ---snip--- NY-N3K-LEAF-11# Again, these steps are straightforward and it shows how we can archive ECMP with static routing for North/South traffic. But what will happen, if for as example one of the two NSX-T Edge Transport Node is down? Lets assume, ny-nsxt-edge-node-20 is down. Traffic from the Spine switches will be forwarded still to both ToR switches and once the ECMP hash is calculated, the traffic is forwarded to one of the four Next Hops (the four Edge Transport Node Layer 3 interfaces). Based on the hash calculation, it could be Next Hop 172.16.160.20 or 172.16.161.20, both interfaces belong to ny-nsxt-edge-node-20. This traffic will be blackholed and dropped! But why do the ToR switches still announce these overlay networks 172.16.240.0/24 and 172.16.241.0/24 to the Spine switches? The reason is simple, because for both ToR switches the static route entries are still valid, as VLAN160/161 or/and the Next Hop are still UP. So from the ToR switch routing table perspective all is fine. These static route entries will potentially never go down, as the Next Hop IP addresses belong to the VLAN 160 or VLAN 161 and these VLANs are always in the state UP as long a single physical port is UP and part of one of these VLANs (assuming the ToR switch is up and running).  Even when all attached ESXi host are down, the InterSwitch link between the ToR switches is still UP and hence VLAN 160 and VLAN 161 are still UP.  Please keep in mind, with BGP this problem does not exists, as we have BGP keepalives and once the NSX-T Edge Transport Node is down, the ToR switch tears down the BGP session and invalidate the local route entries. But how could we solve the blackholing issue with static routing? The answer is Bi-Directional Forwarding (BFD) for static routing. What is BFD? BFD is nothing else then a purpose build keepalive protocol that typically routing protocols including first hop redundancy protocols (e.g. HSRP or VRRP) subscribe to. Various protocols can piggyback a single BFD session. BFD can detect link failures in milliseconds or sub-seconds (NSX-T Bare Metal Edge Nodes with 3 x 50ms) or near sub-seconds (NSX-T VM-based Edge Nodes 3 x 500ms) in the context of NSX-T. All protocols have some way of detecting failure, usually timer-related. Tuning these timers can theoretically get you sub-second failure detection too, but this produces unnecessary high overhead as theses protocols weren't designed with that in mind. BFD was specifically built for fast failure detection and maintain low CPU load. Please keep in mind, if you have as an example BGP running between two physical routers, there's no need to have BFD sessions for link failure detection, as the routing protocol will detect the link-down event instantly. But for two routers (e.g. Tier-0 Gateways) connected through intermediate Layer 2/3 nodes (physical infra, vDS, etc.) where the routing protocol cannot detect a link-down event, the failure event must be detected through a dead timer. Welcome to the virtual world!! BFD was enhanced with the capability to support static routing too, even the driver using BFD for static routing was not the benefit to keep the CPU low and have fast failure detection, it was about extension of the functionality of static routes with keepalives with BFD. So how can we apply BFD for static routing in our lab? There are multiple configuration steps required. Before we can associate BFD with the static routes on the NSX-T Tier-0 Gateway NY-T0-GATEWAY-01, the creation of a BFD profile for static routes is required. This is shown in the diagram below. I am using the same BFD parameter (Interval=500ms and Declare Dead Multiple=3) as NSX-T 3.0 has defined a default for BFD registered for BGP. The next step is the configuration of BFD peers for static routing at Tier-0 Gateway level. I am using the same Next Hop IP addresses (172.16.160.254 and 172.16.161.254) for the BFD peers as I have used for the static routes northbound towards the ToR switches. Again, this BFD peer configuration is configured at Tier-0 Gateway level, but the realization of the BFD peers happens at Edge Transport Node level. On each of the two NSX-T Edge Transport Nodes (Service Router) two BGP sessions are realized. The appropriate BFD peer source interface on the Tier-0 Gateway is automatically selected (the Layer 3 LIF) by NSX-T, but as you see, NSX-T allows you to specify the BFD source interface too. The table below shows the global BFD timer configuration and the BFD peers with source and peer (destination) IP. Table 5 - NSX-T Edge Transport Node BFD Configuration ny-nsxt-edge-node-20 (Service Router) ny-nsxt-edge-node-21 (Service Router) ny-nsxt-edge-node-20(tier0_sr)> get bfd-config Logical Router UUID           : 1cfd7da2-f37c-4108-8f19-7725822f0552 vrf            : 2 lr-id          : 8193 name           : SR-NY-T0-GATEWAY-01 type           : PLR-SR Global BFD configuration     Enabled        : True     Min RX Interval: 500     Min TX Interval: 500     Min RX TTL     : 255     Multiplier     : 3 Port               : 64a2e029-ad69-4ce1-a40e-def0956a9d2d Session BFD configuration    Source         : 172.16.160.20     Peer           : 172.16.160.254     Enabled        : True     Min RX Interval: 500     Min TX Interval: 500     Min RX TTL     : 255     Multiplier     : 3 Port               : 371a9b3f-d669-493a-a46b-161d3536b261 Session BFD configuration     Source         : 172.16.161.20     Peer           : 172.16.161.254     Enabled        : True     Min RX Interval: 500     Min TX Interval: 500     Min RX TTL     : 255     Multiplier     : 3 ny-nsxt-edge-node-20(tier0_sr)> ny-nsxt-edge-node-21(tier0_sr)> get bfd-config Logical Router UUID           : a2ea4cbc-c486-46a1-a663-c9c5815253af vrf            : 1 lr-id          : 8194 name           : SR-NY-T0-GATEWAY-01 type           : PLR-SR Global BFD configuration     Enabled        : True     Min RX Interval: 500     Min TX Interval: 500     Min RX TTL     : 255     Multiplier     : 3 Port               : a5454564-ef1c-4e30-922f-9876b9df38df Session BFD configuration    Source         : 172.16.160.21     Peer           : 172.16.160.254     Enabled        : True     Min RX Interval: 500     Min TX Interval: 500     Min RX TTL     : 255     Multiplier     : 3 Port               : 8423e83b-0a69-44f4-90d1-07d8ece4f55e Session BFD configuration    Source         : 172.16.161.21     Peer           : 172.16.161.254     Enabled        : True     Min RX Interval: 500     Min TX Interval: 500     Min RX TTL     : 255     Multiplier     : 3 ny-nsxt-edge-node-21(tier0_sr)> BFD in general and for static routing as wll requires that the peering site is configured with BFD too to ensure BFD keepalives are send out replied respectively. Once BFD peers are configured on the Tier-0 Gateway, the ToR switches require the appropriate BFD peer configuration too. This is shown in the table below. Each ToR switch gets two BFD peer configurations, one for each of the NSX-T Edge Transport Node. Table 6 - Nexus ToR Switches BFD for Static Routing Configuration NY-N3K-LEAF-10 NY-N3K-LEAF-11 feature bfd ! ip route static bfd Vlan160 172.16.160.20 ip route static bfd Vlan160 172.16.160.21 feature bfd ! ip route static bfd Vlan161 172.16.161.20 ip route static bfd Vlan161 172.16.161.21 Once both ends of the BFD peers are configured correctly, the BFD sessions should come up and the static route should be installed into the routing table. The table below shows the two BFD neighbors for the static routing (interface VLAN160 respective VLAN161). The BFD neighbor for interface Eth1/49 is used for the BFD peer towards the Spine switch and is registered for OSPF.  The NX-OS operating system does not mention "static routing" for the registered protocol, it shows "netstack" - reason unknown. Table 7 - Nexus ToR Switches BFD for Static Routing Configuration and Verification NY-N3K-LEAF-10/11 NY-N3K-LEAF-10# show bfd neighbors OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                  172.16.160.254  172.16.160.20   1090519041/2635291218 Up              1099(3)           Up          Vlan160               default                       172.16.160.254  172.16.160.21   1090519042/3842218904 Up              1413(3)           Up          Vlan160               default                172.16.3.18     172.16.3.17     1090519043/1090519041 Up              5629(3)           Up          Eth1/49               default              NY-N3K-LEAF-10# NY-N3K-LEAF-11# show bfd neighbors OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                  172.16.161.254  172.16.161.20   1090519041/591227029  Up              1384(3)           Up          Vlan161               default                       172.16.161.254  172.16.161.21   1090519042/2646176019 Up              1385(3)           Up          Vlan161               default               172.16.3.22     172.16.3.21     1090519043/1090519042 Up              4696(3)           Up          Eth1/49               default              NY-N3K-LEAF-11# NY-N3K-LEAF-10# show bfd neighbors details OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                    172.16.160.254  172.16.160.20   1090519041/2635291218 Up              1151(3)           Up          Vlan160               default                         Session state is Up and not using echo function Local Diag: 0, Demand mode: 0, Poll bit: 0, Authentication: None MinTxInt: 500000 us, MinRxInt: 500000 us, Multiplier: 3 Received MinRxInt: 500000 us, Received Multiplier: 3 Holdown (hits): 1500 ms (0), Hello (hits): 500 ms (22759) Rx Count: 20115, Rx Interval (ms) min/max/avg: 83/1921/437 last: 348 ms ago Tx Count: 22759, Tx Interval (ms) min/max/avg: 386/386/386 last: 24 ms ago Registered protocols:  netstack Uptime: 0 days 2 hrs 26 mins 39 secs, Upcount: 1 Last packet: Version: 1                - Diagnostic: 0              State bit: Up             - Demand bit: 0              Poll bit: 0               - Final bit: 0              Multiplier: 3             - Length: 24              My Discr.: -1659676078    - Your Discr.: 1090519041              Min tx interval: 500000   - Min rx interval: 500000              Min Echo interval: 0      - Authentication bit: 0 Hosting LC: 1, Down reason: None, Reason not-hosted: None OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                    172.16.160.254  172.16.160.21   1090519042/3842218904 Up              1260(3)           Up          Vlan160               default                         Session state is Up and not using echo function Local Diag: 0, Demand mode: 0, Poll bit: 0, Authentication: None MinTxInt: 500000 us, MinRxInt: 500000 us, Multiplier: 3 Received MinRxInt: 500000 us, Received Multiplier: 3 Holdown (hits): 1500 ms (0), Hello (hits): 500 ms (22774) Rx Count: 20105, Rx Interval (ms) min/max/avg: 0/1813/438 last: 239 ms ago Tx Count: 22774, Tx Interval (ms) min/max/avg: 386/386/386 last: 24 ms ago Registered protocols:  netstack Uptime: 0 days 2 hrs 26 mins 46 secs, Upcount: 1 Last packet: Version: 1                - Diagnostic: 0              State bit: Up             - Demand bit: 0              Poll bit: 0               - Final bit: 0              Multiplier: 3             - Length: 24              My Discr.: -452748392     - Your Discr.: 1090519042              Min tx interval: 500000   - Min rx interval: 500000              Min Echo interval: 0      - Authentication bit: 0 Hosting LC: 1, Down reason: None, Reason not-hosted: None OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                    172.16.3.18     172.16.3.17     1090519043/1090519041 Up              5600(3)           Up          Eth1/49               default                Session state is Up and using echo function with 500 ms interval Local Diag: 0, Demand mode: 0, Poll bit: 0, Authentication: None MinTxInt: 500000 us, MinRxInt: 2000000 us, Multiplier: 3 Received MinRxInt: 2000000 us, Received Multiplier: 3 Holdown (hits): 6000 ms (0), Hello (hits): 2000 ms (5309) Rx Count: 5309, Rx Interval (ms) min/max/avg: 7/2101/1690 last: 399 ms ago Tx Count: 5309, Tx Interval (ms) min/max/avg: 1689/1689/1689 last: 249 ms ago Registered protocols:  ospf Uptime: 0 days 2 hrs 29 mins 29 secs, Upcount: 1 Last packet: Version: 1                - Diagnostic: 0              State bit: Up             - Demand bit: 0              Poll bit: 0               - Final bit: 0              Multiplier: 3             - Length: 24              My Discr.: 1090519041     - Your Discr.: 1090519043              Min tx interval: 500000   - Min rx interval: 2000000              Min Echo interval: 500000 - Authentication bit: 0 Hosting LC: 1, Down reason: None, Reason not-hosted: None NY-N3K-LEAF-10# NY-N3K-LEAF-11# show bfd neighbors details OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                    172.16.161.254  172.16.161.20   1090519041/591227029  Up              1235(3)           Up          Vlan161               default                         Session state is Up and not using echo function Local Diag: 0, Demand mode: 0, Poll bit: 0, Authentication: None MinTxInt: 500000 us, MinRxInt: 500000 us, Multiplier: 3 Received MinRxInt: 500000 us, Received Multiplier: 3 Holdown (hits): 1500 ms (0), Hello (hits): 500 ms (22634) Rx Count: 19972, Rx Interval (ms) min/max/avg: 93/1659/438 last: 264 ms ago Tx Count: 22634, Tx Interval (ms) min/max/avg: 386/386/386 last: 127 ms ago Registered protocols:  netstack Uptime: 0 days 2 hrs 25 mins 47 secs, Upcount: 1 Last packet: Version: 1                - Diagnostic: 0              State bit: Up             - Demand bit: 0              Poll bit: 0               - Final bit: 0              Multiplier: 3             - Length: 24              My Discr.: 591227029      - Your Discr.: 1090519041              Min tx interval: 500000   - Min rx interval: 500000              Min Echo interval: 0      - Authentication bit: 0 Hosting LC: 1, Down reason: None, Reason not-hosted: None OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                    172.16.161.254  172.16.161.21   1090519042/2646176019 Up              1162(3)           Up          Vlan161               default                         Session state is Up and not using echo function Local Diag: 0, Demand mode: 0, Poll bit: 0, Authentication: None MinTxInt: 500000 us, MinRxInt: 500000 us, Multiplier: 3 Received MinRxInt: 500000 us, Received Multiplier: 3 Holdown (hits): 1500 ms (0), Hello (hits): 500 ms (22652) Rx Count: 20004, Rx Interval (ms) min/max/avg: 278/1799/438 last: 337 ms ago Tx Count: 22652, Tx Interval (ms) min/max/avg: 386/386/386 last: 127 ms ago Registered protocols:  netstack Uptime: 0 days 2 hrs 25 mins 58 secs, Upcount: 1 Last packet: Version: 1                - Diagnostic: 0              State bit: Up             - Demand bit: 0              Poll bit: 0               - Final bit: 0              Multiplier: 3             - Length: 24              My Discr.: -1648791277    - Your Discr.: 1090519042              Min tx interval: 500000   - Min rx interval: 500000              Min Echo interval: 0      - Authentication bit: 0 Hosting LC: 1, Down reason: None, Reason not-hosted: None OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                    172.16.3.22     172.16.3.21     1090519043/1090519042 Up              4370(3)           Up          Eth1/49               default                Session state is Up and using echo function with 500 ms interval Local Diag: 0, Demand mode: 0, Poll bit: 0, Authentication: None MinTxInt: 500000 us, MinRxInt: 2000000 us, Multiplier: 3 Received MinRxInt: 2000000 us, Received Multiplier: 3 Holdown (hits): 6000 ms (0), Hello (hits): 2000 ms (5236) Rx Count: 5236, Rx Interval (ms) min/max/avg: 553/1698/1690 last: 1629 ms ago Tx Count: 5236, Tx Interval (ms) min/max/avg: 1689/1689/1689 last: 1020 ms ago Registered protocols:  ospf Uptime: 0 days 2 hrs 27 mins 26 secs, Upcount: 1 Last packet: Version: 1                - Diagnostic: 0              State bit: Up             - Demand bit: 0              Poll bit: 0               - Final bit: 0              Multiplier: 3             - Length: 24              My Discr.: 1090519042     - Your Discr.: 1090519043              Min tx interval: 500000   - Min rx interval: 2000000              Min Echo interval: 500000 - Authentication bit: 0 Hosting LC: 1, Down reason: None, Reason not-hosted: None NY-N3K-LEAF-11# The table below shows the BFD session on the Tier-0 Gateway on the Service Router (SR). The CLI shows the BFD peers and source IP addresses along the state. Please note, BFD does not require that both end of the BFD peer are configured with an identically interval and multiplier value, but for troubleshooting reason are identically parameter recommended. Table 8 - NSX-T Edge Transport Node BFD Verification ny-nsxt-edge-node-20 (Service Router) ny-nsxt-edge-node-21 (Service Router) ny-nsxt-edge-node-20(tier0_sr)> get bfd-sessions BFD Session Dest_port                     : 3784 Diag                          : No Diagnostic Encap                         : vlan Forwarding                    : last true (current true) Interface                     : 64a2e029-ad69-4ce1-a40e-def0956a9d2d Keep-down                     : false Last_cp_diag                  : No Diagnostic Last_cp_rmt_diag              : No Diagnostic Last_cp_rmt_state             : up Last_cp_state                 : up Last_fwd_state                : UP Last_local_down_diag          : No Diagnostic Last_remote_down_diag         : No Diagnostic Last_up_time                  : 2020-07-07 15:42:23 Local_address                 : 172.16.160.20 Local_discr                   : 2635291218 Min_rx_ttl                    : 255 Multiplier                    : 3 Received_remote_diag          : No Diagnostic Received_remote_state         : up Remote_address                : 172.16.160.254 Remote_admin_down             : false Remote_diag                   : No Diagnostic Remote_discr                  : 1090519041 Remote_min_rx_interval        : 500 Remote_min_tx_interval        : 500 Remote_multiplier             : 3 Remote_state                  : up Router                        : 1cfd7da2-f37c-4108-8f19-7725822f0552 Router_down                   : false Rx_cfg_min                    : 500 Rx_interval                   : 500 Service-link                  : false Session_type                  : LR_PORT State                         : up Tx_cfg_min                    : 500 Tx_interval                   : 500 BFD Session Dest_port                     : 3784 Diag                          : No Diagnostic Encap                         : vlan Forwarding                    : last true (current true) Interface                     : 371a9b3f-d669-493a-a46b-161d3536b261 Keep-down                     : false Last_cp_diag                  : No Diagnostic Last_cp_rmt_diag              : No Diagnostic Last_cp_rmt_state             : up Last_cp_state                 : up Last_fwd_state                : UP Last_local_down_diag          : No Diagnostic Last_remote_down_diag         : No Diagnostic Last_up_time                  : 2020-07-07 15:42:24 Local_address                 : 172.16.161.20 Local_discr                   : 591227029 Min_rx_ttl                    : 255 Multiplier                    : 3 Received_remote_diag          : No Diagnostic Received_remote_state         : up Remote_address                : 172.16.161.254 Remote_admin_down             : false Remote_diag                   : No Diagnostic Remote_discr                  : 1090519041 Remote_min_rx_interval        : 500 Remote_min_tx_interval        : 500 Remote_multiplier             : 3 Remote_state                  : up Router                        : 1cfd7da2-f37c-4108-8f19-7725822f0552 Router_down                   : false Rx_cfg_min                    : 500 Rx_interval                   : 500 Service-link                  : false Session_type                  : LR_PORT State                         : up Tx_cfg_min                    : 500 Tx_interval                   : 500 ny-nsxt-edge-node-20(tier0_sr)> ny-nsxt-edge-node-21(tier0_sr)> get bfd-sessions BFD Session Dest_port                     : 3784 Diag                          : No Diagnostic Encap                         : vlan Forwarding                    : last true (current true) Interface                     : a5454564-ef1c-4e30-922f-9876b9df38df Keep-down                     : false Last_cp_diag                  : No Diagnostic Last_cp_rmt_diag              : No Diagnostic Last_cp_rmt_state             : up Last_cp_state                 : up Last_fwd_state                : UP Last_local_down_diag          : No Diagnostic Last_remote_down_diag         : No Diagnostic Last_up_time                  : 2020-07-07 15:42:15 Local_address                 : 172.16.160.21 Local_discr                   : 3842218904 Min_rx_ttl                    : 255 Multiplier                    : 3 Received_remote_diag          : No Diagnostic Received_remote_state         : up Remote_address                : 172.16.160.254 Remote_admin_down             : false Remote_diag                   : No Diagnostic Remote_discr                  : 1090519042 Remote_min_rx_interval        : 500 Remote_min_tx_interval        : 500 Remote_multiplier             : 3 Remote_state                  : up Router                        : a2ea4cbc-c486-46a1-a663-c9c5815253af Router_down                   : false Rx_cfg_min                    : 500 Rx_interval                   : 500 Service-link                  : false Session_type                  : LR_PORT State                         : up Tx_cfg_min                    : 500 Tx_interval                   : 500 BFD Session Dest_port                     : 3784 Diag                          : No Diagnostic Encap                         : vlan Forwarding                    : last true (current true) Interface                     : 8423e83b-0a69-44f4-90d1-07d8ece4f55e Keep-down                     : false Last_cp_diag                  : No Diagnostic Last_cp_rmt_diag              : No Diagnostic Last_cp_rmt_state             : up Last_cp_state                 : up Last_fwd_state                : UP Last_local_down_diag          : No Diagnostic Last_remote_down_diag         : No Diagnostic Last_up_time                  : 2020-07-07 15:42:15 Local_address                 : 172.16.161.21 Local_discr                   : 2646176019 Min_rx_ttl                    : 255 Multiplier                    : 3 Received_remote_diag          : No Diagnostic Received_remote_state         : up Remote_address                : 172.16.161.254 Remote_admin_down             : false Remote_diag                   : No Diagnostic Remote_discr                  : 1090519042 Remote_min_rx_interval        : 500 Remote_min_tx_interval        : 500 Remote_multiplier             : 3 Remote_state                  : up Router                        : a2ea4cbc-c486-46a1-a663-c9c5815253af Router_down                   : false Rx_cfg_min                    : 500 Rx_interval                   : 500 Service-link                  : false Session_type                  : LR_PORT State                         : up Tx_cfg_min                    : 500 Tx_interval                   : 500 ny-nsxt-edge-node-21(tier0_sr)> I would really like to emphasize, that static routing with NSX-T Edge Transport Node in A/A mode must use BFD to avoid blackholing. In case of BFD for static routing is not supported on the ToR switches, then I highly recommend to use A/S mode with HA VIP instead or switch back to BGP. Design Option 2 - Static Routing (A/S HA VIP) The first step in design option 2 is the Tier-0 static route configuration for northbound traffic. The most common way is to configure a default route northbound. The diagram below shows the setup with the two default routes (in black) northbound. As already mentioned, HA VIP requires that both NSX-T Edge Transport Node interfaces belong to the same Layer 2 segment (NY-T0-VLAN-SEGMENT-160). A single default route with with two different Next Hops (172.16.160.254 and 172.16.161.254) is configured on the NY-T0-GATEWAY-02. With this design we could also achieve ECMP for northbound traffic towards the ToR switches. The diagram below shows the corresponding NSX-T Tier-0 Gateway static routing configuration. Please keep in mind again, that at the NSX-T Edge Transport Node level, each Edge Transport Node will have two default route entries even though we have configured only two default routes at Tier-0 Gateway level , not four. This is shown in the table below. Please note, the configuration steps how to configure the Tier-1 Gateway (NY-T1-GATEWAY-BLUE) and how to connect it to the Tier-0 Gateway is not shown. Table 9 - NSX-T Edge Transport Node Routing Table for Design Option 2 (A/S HA VIP) ny-nsxt-edge-node-22 (Service Router) ny-nsxt-edge-node-23 (Service Router) ny-nsxt-edge-node-22(tier0_sr)> get route 0.0.0.0/0 Flags: t0c - Tier0-Connected, t0s - Tier0-Static, b - BGP, t0n - Tier0-NAT, t1s - Tier1-Static, t1c - Tier1-Connected, t1n: Tier1-NAT, t1l: Tier1-LB VIP, t1ls: Tier1-LB SNAT, t1d: Tier1-DNS FORWARDER, t1ipsec: Tier1-IPSec, isr: Inter-SR, > - selected route, * - FIB route Total number of routes: 1 t0s> * 0.0.0.0/0 [1/0] via 172.16.160.253, uplink-278, 00:00:27 t0s> * 0.0.0.0/0 [1/0] via 172.16.160.254, uplink-278, 00:00:27 ny-nsxt-edge-node-22(tier0_sr)> ny-nsxt-edge-node-23(tier0_sr)> get route 0.0.0.0/0 Flags: t0c - Tier0-Connected, t0s - Tier0-Static, b - BGP, t0n - Tier0-NAT, t1s - Tier1-Static, t1c - Tier1-Connected, t1n: Tier1-NAT, t1l: Tier1-LB VIP, t1ls: Tier1-LB SNAT, t1d: Tier1-DNS FORWARDER, t1ipsec: Tier1-IPSec, isr: Inter-SR, > - selected route, * - FIB route Total number of routes: 1 t0s> * 0.0.0.0/0 [1/0] via 172.16.160.253, uplink-279, 00:00:57 t0s> * 0.0.0.0/0 [1/0] via 172.16.160.254, uplink-279, 00:00:57 ny-nsxt-edge-node-23(tier0_sr)> The second step is to configure static routing southbound from the ToR switches towards NSX-T Edge Transport Node. Each ToR switch is configured with two static routes to forward traffic to the destination overlay networks (overlay segments 172.16.242.0/24 and 172.16.243.0/24) within NSX-T. For each of the static routes the Next Hop is the NSX-T Tier-0 Gateway HA VIP. The table below shows the static routing configuration on the ToR switch and the resulting routing table. The Next Hop is the Tier-0 Gateway HA VIP 172.16.160.24 for all static routes. Table 10 - Nexus ToR Switches Static Routing Configuration and Resulting Routing Table for Design Option 2 (A/S HA VIP) NY-N3K-LEAF-10 NY-N3K-LEAF-11 ip route 172.16.242.0/24 Vlan160 172.16.160.24 ip route 172.16.243.0/24 Vlan160 172.16.160.24 ip route 172.16.242.0/24 Vlan160 172.16.160.24 ip route 172.16.243.0/24 Vlan160 172.16.160.24 NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 02:51:34, static     *via 172.16.160.21, Vlan160, [1/0], 02:51:41, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 02:51:34, static     *via 172.16.160.21, Vlan160, [1/0], 02:51:41, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 02:55:42, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 02:55:42, static NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 02:53:04, static     *via 172.16.161.21, Vlan161, [1/0], 02:53:12, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 02:53:04, static     *via 172.16.161.21, Vlan161, [1/0], 02:53:12, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 02:55:03, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 02:55:03, static NY-N3K-LEAF-11# Failover Sanity checks The table below Table 11 - Failover Sanity Check Failover Case NY-N3K-LEAF-10 (Routing Table) NY-N3K-LEAF-11 (Routing Table) Comments All NSX-T Edge Transport Nodes are UP NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 00:58:27, static     *via 172.16.160.21, Vlan160, [1/0], 00:58:43, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 00:58:27, static     *via 172.16.160.21, Vlan160, [1/0], 00:58:43, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:02:47, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:02:47, static NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 00:59:10, static     *via 172.16.161.21, Vlan161, [1/0], 00:59:25, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 00:59:10, static     *via 172.16.161.21, Vlan161, [1/0], 00:59:25, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:01:21, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:01:21, static NY-N3K-LEAF-11# NSX-T Edge Transport Node ny-nsxt-edge-node-20 is DOWN All other NSX-T Edge Transport Node are UP NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 1/0     *via 172.16.160.21, Vlan160, [1/0], 01:01:01, static 172.16.241.0/24, ubest/mbest: 1/0     *via 172.16.160.21, Vlan160, [1/0], 01:01:01, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:05:05, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:05:05, static NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 1/0     *via 172.16.161.21, Vlan161, [1/0], 01:01:21, static 172.16.241.0/24, ubest/mbest: 1/0     *via 172.16.161.21, Vlan161, [1/0], 01:01:21, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:03:17, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:03:17, static NY-N3K-LEAF-11# Route entries with ny-nsxt-edge-node-20 (172.16.160.20 and 172.16.161.20) are removed by BFD NSX-T Edge Transport Node ny-nsxt-edge-node-21 is DOWN All other NSX-T Edge Transport Node are UP NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 1/0     *via 172.16.160.20, Vlan160, [1/0], 00:02:40, static 172.16.241.0/24, ubest/mbest: 1/0     *via 172.16.160.20, Vlan160, [1/0], 00:02:40, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:12:13, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:12:13, static NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 1/0     *via 172.16.161.20, Vlan161, [1/0], 00:03:04, static 172.16.241.0/24, ubest/mbest: 1/0     *via 172.16.161.20, Vlan161, [1/0], 00:03:04, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:10:28, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:10:28, static NY-N3K-LEAF-11# Route entries with ny-nsxt-edge-node-21 (172.16.160.21 and 172.16.161.21) are removed by BFD NSX-T Edge Transport Node ny-nsxt-edge-node-22 is DOWN All other NSX-T Edge Transport Node are UP NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 00:06:55, static     *via 172.16.160.21, Vlan160, [1/0], 00:00:09, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 00:06:55, static     *via 172.16.160.21, Vlan160, [1/0], 00:00:09, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:16:28, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:16:28, static NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 00:07:01, static     *via 172.16.161.21, Vlan161, [1/0], 00:00:16, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 00:07:01, static     *via 172.16.161.21, Vlan161, [1/0], 00:00:16, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:14:25, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:14:25, static NY-N3K-LEAF-11# A single NSX-T Edge Transport Node down used for HA VIP does not change the routing table NSX-T Edge Transport Node ny-nsxt-edge-node-23 is DOWN All other NSX-T Edge Transport Node are UP NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 00:10:58, static     *via 172.16.160.21, Vlan160, [1/0], 00:04:12, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.160.20, Vlan160, [1/0], 00:10:58, static     *via 172.16.160.21, Vlan160, [1/0], 00:04:12, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:20:31, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:20:31, static NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.240.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 00:11:30, static     *via 172.16.161.21, Vlan161, [1/0], 00:04:45, static 172.16.241.0/24, ubest/mbest: 2/0     *via 172.16.161.20, Vlan161, [1/0], 00:11:30, static     *via 172.16.161.21, Vlan161, [1/0], 00:04:45, static 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:18:54, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:18:54, static NY-N3K-LEAF-11# A single NSX-T Edge Transport Node down used for HA VIP does not change the routing table NSX-T Edge Transport Node ny-nsxt-edge-node-20 and ny-nsxt-edge-node-21 are DOWN All other NSX-T Edge Transport Node are UP NY-N3K-LEAF-10# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:24:06, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:24:06, static NY-N3K-LEAF-10# NY-N3K-LEAF-11# show ip route static IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 172.16.242.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:22:54, static 172.16.243.0/24, ubest/mbest: 1/0     *via 172.16.160.24, Vlan160, [1/0], 01:22:54, static NY-N3K-LEAF-11# All route entries related to design option 1 are removed by BFD I hope you had a little bit of fun reading this blog post about a static routing with NSX-T. Now with the knowledge how to archive ECMP with static routing, you might have a new and interessting design option for your customers NSX-T deployments. Software Inventory: vSphere version: VMware ESXi, 6.5.0, 15256549 vCenter version: 6.5.0, 10964411 NSX-T version: 3.0.0.0.0.15946738 (GA) Cisco Nexus 3048 NX-OS version: 7.0(3)I7(6) Blog history Version 1.0 - 08.07.2020 - first published version Version 1.1 - 09.07.2020 - minor changes Version 1.2 - 30.07.2020 - grammar updates - thanks to James Lepthien

VMware製品の調査をしていると、製品が内部に持つ管理DBの中身を見ることがあります。 管理DBの中身を見る方法は、実機で直接DBに接続してSQLコマンドをたたく方法と、Dumpされたテキストファイルを見る方法がありますが、 このブログでは3回に分けてDumpされたDBをローカルのPostgreSQLにインポートして、ローカルで調査する方法を紹介したいと思います。 第一回はSDDC ManagerとvCenterの内部管理DBのDump方法について紹介します。 ※筆者はPostgreSQLに関する知識は素人に毛が生えたレベルですので不正確な部分についてご容赦ください。また、DB Dumpなどの方法についてはVMwareから提供されている方法を正としていただき、本ブログはあくまでも参考情報としてご利用ください。 第2回、第3回の記事は以下です。 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】 全体の流れを確認 DB Dumpの取得方法を説明する前に、3回にわたる今回の記事の流れを説明します。 ゴールはVCSAとSDDC ManagerのDBの中身をローカルPCにInstall したPostgreSQL DBMSで閲覧することです。 DBの情報をローカルにコピーする必要があるため、DBの中身をDumpし、それをインポートする流れになります。 そのため、第一回では対象のDBのDumpを取得する方法を説明します。 第二回では実際にDB DumpをインポートするPostgreSQL DBをWindows PCにInstallする手順を示します。 第三回では、DB Dumpを実際にインポートする手順と注意事項などについて説明します。 SDDC ManagerのDBダンプ取得方法 SDDC Managerの管理DBのDump方法は非常に簡単です。 SDDC Managerのログバンドルを取得するとその中に含まれています。 SDDC Managerはsos utilityで取得できますが、実行の際に--sddc-manager-logs オプションをつけることでSDDC Managerのログバンドルを明示的に指定して取得可能です。 sos utilityを用いたログ採取については下記もご参考ください。 Cloud Foundation システムのログの収集 ログバンドルの中にpostgres-db-dumpというファイルがありますので、こちらがDB Dumpに相当します。 VCDB (vCenter内部管理DB)のダンプ取得方法 こちらについては、VMwareの公式情報が見つからなかったのであくまでもPostgreSQL観点での実施方法になります。 なお、今回の検証で利用しているのは、vCenter Server Applianceの6.7.0-15132721です。 0. VCSAのサービスを停止 DB dumpを取得する前に、VCSAのサービスを停止しましょう。 以下のVMware KBを参考にしてください。。 https://kb.vmware.com/s/article/2109887?lang=ja 1. postgres ユーザのパスワードを確認する VCSA内のPostgreSQL DBのpostgres ユーザのパスワードを確認します。 パスワードは.pgpassファイルに書かれており、以下のコマンドで中身を確認できます。 # cat /root/.pgpass 2. postgreSQL DBのDumpを取得する パスワードを確認したらDB Dumpを取得します。 DBのDumpはサイズが大きくなることが想定されるのであらかじめ、容量に余裕のある場所に生成するようにします。 本記事では/storage/core 配下に保存することにします。 /storage/coreはデフォルトで50GBが割り当てられており、障害が発生しない限りほとんど空いてます。 #  cd /storage/core/ 次にpg_dumpallコマンドでダンプを取得します。以下のコマンドを実行するだけでOKです。 #  pg_dumpall -U postgres > vcdb_dump ファイル名はなんでもいいです。 コマンドを実行するとパスワードが求められますので、１．のステップで確認したパスワードを入力してください。 パスワードを間違えるとエラーメッセージが出ますが、何も出ずにプロンプトが返れば成功です。 3. TableSpaceのファイルもまとめて.tgzに固める VCDBの一部は別の場所に保存されているのでそちらも採取しておく必要があります。 2．のステップで取得したDumpファイルと合わせてtarで固めて圧縮し、転送しやすくしましょう。 以下のコマンドで十分です。 # tar cvzf vcdb_dump.tgz vcdb_dump /storage/seat/vpostgres/* vcdb_dump.tgz がカレントディレクトリ（/storage/core）に生成されているはずなので、これをローカルのPCに転送しましょう。 4. VCSAのサービス起動 DB Dump採取前に停止したサービスは忘れずに起動してください。 今回は、vCenterとSDDC Managerの内部管理用PostgreSQL DBMSのDump方法について紹介しました。 次回はローカルPCにPostgreSQL DBMSをインストールする方法を紹介します。 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

Symptoms After upgrading the operating system where VMware componenets are installed, you experience these symptoms: You are unable to start the VMware VirtualCenter Server, VMware VirtualCenter Management Webservices, or VMware vSphere Web Client service Starting a service fails with the error: Error 1075: The dependency service does not exist or has been marked for deletion The operating system was upgraded to Microsoft Windows Server 2012 R2 from Windows Server 2008 R2 Cause This issue occurs due to the change of services and service names in Microsoft Windows Server 2012 R2. In Microsoft Windows Server 2008 R2, the VMware Virtual Center Server and VMware vSphere Web Client services are dependent on the Protected Storage service. In Microsoft Windows Server 2012 R2, the Protected Storage service is renamed to the Security Accounts Manager service. During the operating system upgrade, the VMware service dependencies are not updated with the new service names. This results in the VMware Virtual Center Server service not being able to start as the Protected Storage service no longer exists. I followed this KB (2112741) VMware Knowledge Base

前回は、vSphere with Kubernetes のラボ環境で、Tanzu Kubernetes Cluster 作成の準備作業をしました。 今回は Tanzu Kubernetes Cluster を作成してみます。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編 Tanzu Kubernetes Grid（TKG）サービスで利用されている Cluster API では、 Management Cluster と Workload Cluster という役割の Kubernetes クラスタが登場しますが、 今回作成する Tanzu Kubernetes Cluster は、Workload Cluster にあたります。 Supervisor Cluster への接続。 kubectl で、Supervisor Cluster に接続します。 vSphere 専用の kubectl の準備については、下記の投稿のようにしています。 vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編 kubectl では、下記のようログインにしてます。 この環境では Supervisor Cluster の Control Plane アドレスとして、192.168.70.33 を指定します。 このあとの対話入力で、administrator@vsphere.local とパスワードを入力。 $ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33 環境の確認。 前回の準備をふまえて、あらためて環境確認をしておきます。 今回は、名前空間「lab-ns-02」に Tanzu Kuberntes Cluster を作成するので、 同名の Context に切りかえておきます。 $ kubectl config use-context lab-ns-02 Switched to context "lab-ns-02". 作成されている Storage Class です。 あとで Tanzu Kuberntes Cluster の設定値として YAML で指定するので、 「vm-storage-policy-wcp」という名前をひかえておきます。 $ kubectl get storageclasses NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h 名前空間へのコンテンツ ライブラリ追加により、VirtualMachineImage の情報取得ができるようになっています。 イメージの名前（NAME 列）の文字列から、このあとの YAML では Kubernetes バージョン「v1.16.8」を指定します。 $ kubectl get virtualmachineimages NAME                                                        VERSION                          OSTYPE ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest Tanzu Kuberntes Cluster の YAML 作成。 Tanzu Kuberntes Cluster の設定値を記載したマニュフェストを、YAML 形式のファイルとして作成します。 tkg-cluster-01.yml --- kind: TanzuKubernetesCluster apiVersion: run.tanzu.vmware.com/v1alpha1 metadata:   name: tkg-cluster-01 spec:   distribution:     version: v1.16.8   topology:     controlPlane:       count: 3       class: best-effort-xsmall       storageClass: vm-storage-policy-wcp     workers:       count: 3       class: best-effort-xsmall       storageClass: vm-storage-policy-wcp   settings:     network:       cni:         name: calico       services:         cidrBlocks: ["198.51.100.0/12"] # Cannot overlap with Supervisor Cluster       pods:         cidrBlocks: ["192.0.2.0/16"]    # Cannot overlap with Supervisor Cluster     storage:       classes: ["vm-storage-policy-wcp"]  # Named PVC storage classes       defaultClass: vm-storage-policy-wcp # Default PVC storage class YMAL では、下記のようにパラメータを指定しています。 Kubernetes のバージョンは、コンテンツ ライブラリに登録されている OVF テンプレート （にもどづく VirtualMachineImage の名前）の文字列を指定します。 ここでは省略して「v1.16.8」と指定しています。 spec.distribution.version 各所で指定している「vm-storage-policy-wcp」は、 名前空間へのストレージ ポリシー追加で自動的に作成・利用可能になった、 仮想マシン ストレージ ポリシーと同名の StorageClass です。 CIDR によるアドレス範囲は、Supervisor Cluster とは別のものを指定します。 ちなみに、Pod Network の CNI では、Calico が使用されます。 spec.settings.network.services.cidrBlocks spec.settings.network.pods.cidrBlocks Control Plane ノード、Worker ノードは、それぞれ 3ノードです。 spec.topology.controlPlane.count spec.topology.worker.count Control Plane ノード、Worker ノードの VM スペックは、下記で指定しています。 ここでは、「best-effort-xsmall」を指定しています。 spec.topology.controlPlane.class spec.topology.worker.class ここで指定している class（VirtualMachineClass）には、下記が用意されています。 $ kubectl get virtualmachineclasses NAME                 AGE best-effort-large    12d best-effort-medium   12d best-effort-small    12d best-effort-xlarge   12d best-effort-xsmall   12d guaranteed-large     12d guaranteed-medium    12d guaranteed-small     12d guaranteed-xlarge    12d guaranteed-xsmall    12d ちなみに、今回指定した VirtualMachineClass「best-effort-xsmall」は、下記のようなスペックです。 vCPU は 2個（cpus: 2）、メモリ容量は 2GiB（memory: 2Gi）です。 $ kubectl get virtualmachineclasses best-effort-xsmall -o yaml apiVersion: vmoperator.vmware.com/v1alpha1 kind: VirtualMachineClass metadata:   annotations:     kubectl.kubernetes.io/last-applied-configuration: |       {"apiVersion":"vmoperator.vmware.com/v1alpha1","kind":"VirtualMachineClass","metadata":{"annotations":{},"name":"best-effort-xsmall"},"spec":{"hardware":{"cpus":2,"memory":"2Gi"}}}   creationTimestamp: "2020-05-24T15:20:10Z"   generation: 1   name: best-effort-xsmall   resourceVersion: "2182"   selfLink: /apis/vmoperator.vmware.com/v1alpha1/virtualmachineclasses/best-effort-xsmall   uid: b5a801bc-28d4-4526-966b-7e30dbc9b570 spec:   hardware:     cpus: 2     memory: 2Gi Tanzu Kubernetes Cluster の作成。 それでは、Tanzu Kubernetes Cluster を作成します。 用意した YAML を指定して、kubectl apply を実行します。 $ kubectl apply -f ./tkg-cluster-01.yml tanzukubernetescluster.run.tanzu.vmware.com/tkg-cluster-01 created しばらく待つと、lab-ns-02 名前空間に、Kubernetes のノードになる VM がデプロイ、起動されます。 これらの VM（のゲスト OS）で、Tanzu Kubernetes Cluster が構成されています。 Kubernetes のバージョンは、v1.16.8 になっています。 これは、Supervisor Cluster の Kubernetes バージョンと一致するわけではありません。 kubectl でログイン先として指定する、制御プレーンのアドレスもわかります。 （これは、Supervisor Cluster への接続と同じアドレスです） YAML で指定したとおり、Kubernetes Node が VM で作成されています。 Control Plane Node（VM 名は、＜クラスタ名＞-control-plane-～） が 3 VM、 Worker Node（VM 名は、＜クラスタ名＞-worker-～）が 3 VM 作成されています。 どちらも、仮想マシン クラスは、best-effort-xsmall になっています。 続く？ vSphere with Kubernetes ラボ環境構築。Part-14: Tanzu Kubernetes Cluster への接続 / Pod 起動編

ここまでに、vSphere with Kubernetes のラボ環境を構築して、 名前空間（Supervisor Namespace）に vSphere Pod を起動してみました。 前回の投稿はこちら。 vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編 vSphere with Kubernetes では、おもに 2種類の方法でコンテナを起動できます。 Supervisor Cluster（ESXi が Kubernetes Worker ノード）の上で、vSphere Pod を起動する。※前回の投稿。 Supervisor Cluster のうえに、さらに ゲスト OS による Kubernetes クラスタ（Tanzu Kubernetes Cluster）を作成して、その上で Pod を起動する。 今回から、前回までに構築した Subervisor Cluster に、Tanzu Kubernetes Cluster のデモ環境を構築していきます。 つまり、Supervisor Namespace に Tanzu Kubernetes Grid サービスによる Kubernetes Cluster （ドキュメントでは Tanzu Kubernetes Cluster）を作成してみます。 vSphere with Kubernetes での Tanzu Kubernetes クラスタの実行 Tanzu Kubernetes Grid（TKG）は、Cluster API という Kubernetes クラスタ自体のライフサイクルを管理できる API を利用しています。 Cluster API では、おもに 2種類の Kubernetes クラスタが登場します。 Management Cluster Kubernetes クラスタを管理するための Kubernetes クラスタ。 vSphere with Kubernetes の TKG では、Subervisor Cluster が Management Cluster になる。 Workload Cluster 実際になにかしたいワークロードを展開するための Kubernetes クラスタ。 vSphere with Kubernetes の TKG では、Subervisor Cluster の名前空間に VM がデプロイされて、そのゲスト OS でさらに Kubernetes クラスタが作成される。 ここからは、Management Cluster での準備作業です。 コンテンツ ライブラリの準備。 TKG では、Kubernetes ノードになる VM のテンプレートを利用します。 そして、vSphere with Kubernetes の TKG では、VM テンプレートの配置に vCenter のコンテンツ ライブラリを利用します。 ここでは、TKG で利用するコンテンツ ライブラリを作成して、コンテンツを同期（インターネット経由でダウンロード）しておきます。 vSphere Client で、「コンテンツ ライブラリ」メニューを開きます。 「作成」ボタンをクリックして、「新しいコンテンツ ライブラリ」画面を開きます。 コンテンツ ライブラリの名前は「lib-tkg-01」にしています。 「コンテンツ ライブラリの設定」では、次のように入力して「NEXT」をクリックします。 「サブスクライブ済み コンテンツ」を選択 サブスクリプション URL を入力： https://wp-content.vmware.com/v2/latest/lib.json ※製品ドキュメントにある URL です。 コンテンツのダウンロード： 今すぐ（デフォルトのまま） ストレージの追加では、ダウンロードされたコンテンツを格納するデータストアを選択します。 コンテンツ ライブラリが作成されました。 しばらく待つと、コンテンツ ライブラリの同期が完了します。 この処理は 5GB を超えるファイルのダウンロードなので、そこそこ時間がかかります。 ※「ライブラリの同期」タスクは 0% の状態が長く続きます。 同期の完了したコンテンツ ライブラリで、名前（lib-tkg-01）をクリックします。 「OVF & OVA テンプレート」を開くと、 Kubernetes ノードになる VM テンプレートが見つかります。 名前の文字列から、Kubernetes のバージョンが v1.16.8 であることがわかります。 名前空間でのコンテンツ ライブラリ追加。 名前空間で、TKG が VM テンプレートをさがすコンテンツ ライブラリを追加します。 名前空間（ここでは lab-ns-02）の「サマリ」→「Tanzu Kubernetes」で、 「ライブラリの追加」をクリックします。 「ライブラリの追加」をクリックします。 ※名前空間の「設定」→「名前空間」→「全般」を直接ひらいても大丈夫です。 先ほど作成・同期したコンテンツ ライブラリを選択し、「OK」をクリックします。 コンテンツ ライブラリが追加されました。 これにより、Kubernetes の VirtualMachineImage リソースが作成されます。 kubectl で接続（前回の投稿参照）すれば、下記のようにリソースの存在を確認できます。 $ kubectl get virtualmachineimages NAME                                                        VERSION                          OSTYPE ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest 名前空間への仮想マシン ストレージ ポリシーの追加。 名前空間に、仮想マシン ストレージ ポリシーを追加します。 この手順により、この仮想マシン ストレージ ポリシーによってデータストアを利用する、Kubernetes の StorageClass リソースが用意されます。 名前空間（ここでは lab-ns-02）の「サマリ」→「ストレージ」で、「ストレージの追加」をクリックします。 仮想マシン ストレージ ポリシーを選択して、「OK」をクリックします。 名前空間に、仮想マシン ストレージ ポリシーが追加されました。 これにより、Kubernetes の StorageClasse リソースが作成されます。 kubectl で接続（前回の投稿参照）すれば、下記のようにリソースの存在を確認できます。 $ kubectl get storageclasses NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h つづく・・・。 vSphere with Kubernetes ラボ環境構築。Part-13: Supervisor Namespace での Tanzu Kubernetes Cluster 作成編

vSphere with Kubernetes を体験するためのラボ環境構築をしたので、 kubectl で接続して、コンテナ を Kubernetes の Pod（vSphere Pod）として起動してみます。 Supervisor Cluster に作成した名前空間の配下の管理は、基本的には vSphere 専用の kubectl を利用します。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編 クライアント環境について。 今回は、kubectl を実行するクライアントとして Linux（VMware Photon OS 3.0）を利用しています。 gowatana [ ~ ]$ cat /etc/photon-release VMware Photon OS 3.0 PHOTON_BUILD_NUMBER=49d932d Photon OS はデフォルトのパッケージが少ないので、 あらかじめ root ユーザで RPM を追加インストールしておきます。 photon-checksum-generator： ハッシュ値確認のため（sha256sum コマンド） unzip： kubectl の zip ファイル（vsphere-plugin.zip）の解凍のため。 root@vm01 [ ~ ]# tdnf install -y photon-checksum-generator unzip kubectl のダウンロード ページ。 まず、vSphere 専用の kubectl をダウンロードします。 この環境の Supervisor Cluster には、名前空間「lab-ns-01」、「lab-ns-02」を作成してあります。 ダウンロード サイトには、「名前空間」のサマリページにある「開く」リンクからアクセスできます。 「Kubernetes CLI Tools」ページが開けます。 ちなみに、このサイトのアドレスは、Supervisor Control Plane VM （のアドレスをメンバにしている NSX-T の LB の VIP）のものです。 Web ブラウザのアドレスバーを見ると、今回の IP アドレスは、192.168.70.33 になっています。 このあとの kubectl での接続先も、この IP アドレスです。 ダウンロードサイトでは、Windows / Linux / Mac OS 用の kubectl と、 それぞれの SHA256 ハッシュ値のファイルが提供されます。 OS ごとの kubectl の利用手順も、このページに記載されています。 kubectl のダウンロード ～ ログイン。 「Kubernetes CLI Tools」ページにある「CLI PLUGIN LINUX」と「Checksum CLI plugin Linux」から 右クリック メニューなどでダウンロード URL を取得しておきます。 そして、今回 kubectl を実行する Linux からダウンロードします。 kubectl の zip ファイル（vsphere-plugin.zip）を、curl でダウンロードします。 gowatana [ ~ ]$ curl -k -L -O https://192.168.70.33/wcp/plugin/linux-amd64/vsphere-plugin.zip あわせて、ハッシュ値のファイル（sha256sum.txt）をダウンロードします。 gowatana [ ~ ]$ curl -k -L -O https://192.168.70.33/wcp/plugin/linux-amd64/sha256sum.txt 2つのファイルをダウンロードしたら、SHA256 のハッシュ値でファイルに問題がなそうか確認しておきます。 Photon OS 3.0 では、「Kubernetes CLI Tools」ページとは少し手順が異なり、 冒頭での photon-checksum-generator のインストールが必要です。 とりあえず実行してみるだけであれば、ハッシュ値確認は省略しても大丈夫です。 gowatana [ ~ ]$ ls sha256sum.txt  vsphere-plugin.zip gowatana [ ~ ]$ tdnf install -y photon-checksum-generator gowatana [ ~ ]$ sha256sum --check sha256sum.txt < vsphere-plugin.zip vsphere-plugin.zip: OK zunzip でファイルを解凍すると、中に kubectl が入っています。 gowatana [ ~ ]$ unzip vsphere-plugin.zip Archive:  vsphere-plugin.zip    creating: bin/   inflating: bin/kubectl-vsphere   inflating: bin/kubectl kubectl に PATH を通しておきます。 gowatana [ ~ ]$ export PATH=$(pwd)/bin:$PATH gowatana [ ~ ]$ which kubectl /home/gowatana/bin/kubectl 今回の kubectl のバージョンです。 gowatana [ ~ ]$ kubectl version --client Client Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.4-2+a00aae1e6a4a69", GitCommit:"a00aae1e6a4a698595445ec86aab1502a495c1ce", GitTreeState:"clean", BuildDate:"2020-04-22T11:35:29Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"} kubectl で Bash の Tab キー補完を利用するためのコマンドラインを実行しておきます。 gowatana [ ~ ]$ source <(kubectl completion bash) ちなみに、Photon OS ではなく RHEL / CentOS などを利用する場合、 この Bash 補完機能を利用するためには、bash-completion のインストールと再ログインが必要だったりします。 [root@centos7 ~]# yum install -y bash-completion ダウンロードした kubectl には、一般的な kubectl にはない「kubectl vsphere ～」といったコマンドがあります。 gowatana [ ~ ]$ kubectl vsphere --help vSphere Plugin for kubectl. Usage:   kubectl-vsphere [command] Available Commands:   help        Help about any command   login       Authenticate user with vCenter Namespaces   logout      Destroys current sessions with all vCenter Namespaces clusters.   version     Prints the version of the plugin. Flags:   -h, --help                     help for kubectl-vsphere       --request-timeout string   Request timeout for HTTP client.   -v, --verbose int              Print verbose logging information. Use "kubectl-vsphere [command] --help" for more information about a command. 「kubectl vsphere login」で、Supervisor Control VM のアドレス宛にログインします。 gowatana [ ~ ]$ kubectl vsphere login --help Authenticate user with vCenter Namespaces: To access Kubernetes, you must first authenticate against vCenter Namespaces. You must pass the address of the vCenter Namspaces server and the username of the user to authenticate, and will be prompted to provide further credentials. Usage:   kubectl-vsphere login [flags] Examples: kubectl vsphere login --vsphere-username user@domain --server=https://10.0.1.10 https://10.0.1.10/Flags:   -h, --help                                        help for login       --insecure-skip-tls-verify                    Skip certificate verification (this is insecure).       --server string                               Address of the server to authenticate against.       --tanzu-kubernetes-cluster-name string        Name of the Tanzu Kubernetes cluster to login to.       --tanzu-kubernetes-cluster-namespace string   Namespace in which the Tanzu Kubernetes cluster resides.   -u, --vsphere-username string                     Username to authenticate. Global Flags:       --request-timeout string   Request timeout for HTTP client.   -v, --verbose int              Print verbose logging information. 今回は、vCenter の名前空間で特にアクセス権限を付与していないので、 デフォルトでアクセス可能になっている administrator@vsphere.local ユーザでログインします。 接続先は、vCenter ではなく、Supervisor Control VM にアクセスできる VIP アドレス「192.168.70.33」です。さきほどの 「Kubernetes CLI Tools」ページと同じアドレスになるはずです。 証明書エラーを回避するため、「--insecure-skip-tls-verify」を指定しています。 gowatana [ ~ ]$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33 Username: administrator@vsphere.local Password: ★パスワード入力 Logged in successfully. You have access to the following contexts:    192.168.70.33    lab-ns-01    lab-ns-02 If the context you wish to use is not in this list, you may need to try logging in again later, or contact your cluster administrator. To change context, use `kubectl config use-context <workload name>` 利用可能な Context が表示されるので、 名前空間「lab-ns-01」にアクセスできる、同名のコンテキストに切り替えます。 gowatana [ ~ ]$ kubectl config use-context lab-ns-01 Switched to context "lab-ns-01". Pod の起動確認。（kubectl run） まずは、kubectl コマンドで CentOS 7 のコンテナを Kubernetes の Pod として起動してみます。 下記のようなオプション指定で、まずは コンテナが起動できることだけ確認します。 コンテナ イメージは centos:7 を Docker Hubからダウンロードしています。 「-it」 オプションで起動したコンテナにそのまま接続しています。 「--rm」オプションで、コンテナから抜けた（exit した）際に、Pod を削除します。 コンテナを起動し、そのまま接続して、CentOS であることを確認してみました。 gowatana [ ~ ]$ kubectl run -it --image=centos:7 --generator=run-pod/v1 --rm centos If you don't see a command prompt, try pressing enter. [root@centos /]# ★ここからコンテナの中。 [root@centos /]# [root@centos /]# cat /etc/centos-release CentOS Linux release 7.8.2003 (Core) この状態で vSphere Client から名前空間「lab-ns-01」を確認すると、 「centos」という名前のコンテナを含む Pod が作成、起動されています。 exit で抜けると、「--rm」オプションにより自動的にコンテナは削除されます。 [root@centos /]# exit exit Session ended, resume using 'kubectl attach centos -c centos -i -t' command when the pod is running pod "centos" deleted gowatana [ ~ ]$ vSphere Client でも、Pod が削除される様子が確認できます。 ちなみに、タスク名が「仮想マシンの削除」なのは、vSphere Pod では Pod が仮想マシンとして起動されているためです。 Pod の起動確認。（kubectl apply） Kubernetes へのコンテナの展開は、実際には YAML ファイルを利用するのが一般的です。 そこで、YAML ファイルを用意して Pod を起動してみます。 下記のような nginx-pod.yml ファイルを用意します。 nginx イメージによる nginx-container コンテナ 1つを含む、nginx-pod という Pod を作成します。 --- kind: Pod apiVersion: v1 metadata:   name: nginx-pod   labels:     app: wcp-demo spec:   containers:   - image: nginx     name: nginx-container nginx-pod.yml  ファイルは、たとえば vi などのテキスト エディタで作成・・・ gowatana [ ~ ]$ vi nginx-pod.yml もしくは下記のように ファイルを作成します。 gowatana [ ~ ]$ cat << EOF > nginx-pod.yml > --- > kind: Pod > apiVersion: v1 > metadata: >   name: nginx-pod >   labels: >     app: wcp-demo > spec: >   containers: >   - image: nginx >     name: nginx-container > EOF gowatana [ ~ ]$ cat ./nginx-pod.yml --- kind: Pod apiVersion: v1 metadata:   name: nginx-pod   labels:     app: wcp-demo spec:   containers:   - image: nginx     name: nginx-container kubectl apply コマンドで YAML ファイルを指定して、Pod を起動してみます。 gowatana [ ~ ]$ kubectl apply -f nginx-pod.yml pod/nginx-pod created Pod の起動が、kubectl で確認できます。 gowatana [ ~ ]$ kubectl get pods NAME        READY   STATUS    RESTARTS   AGE nginx-pod   1/1     Running   0          40s vSphere Client でも、Pod が起動された様子が確認できます。 ちなみに、今回はただ Pod を起動しただけなので、Nginx に Web アクセスするには別途手順が必要です。 vSphere with Kubernetes の機能は NSX-T を前提としており、kubectl での操作に合わせて、 NSX によるネットワークが自動的に設定変更されます。（これについては別途・・・） kubectl delete コマンドで Pod を削除すると、 vSphere Client でも Pod が削除された様子がわかるはずです。 gowatana [ ~ ]$ kubectl delete pod -f nginx-pod.yml pod "nginx-pod" deleted このように、vSphere with Kubernetes のでの Kubernetes ワークロードの操作については、 vSphere Client ではなく、基本的に kubectl を利用します。 以上、Supervisor Cluster に kubectl でアクセスして Pod を起動してみる話でした。 次は・・・ vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

本記事ではVxRailのESXi Imageに目的のFixが含まれているかを確認します。 VxRail の ESXi ImageとVMwareのESXi Imageの差異について VxRailには、ESXiのImageが含まれています。 しかしながら、VxRailのESXi ImageはVMwareから公開されているESXi Imageと必ず同じとは限らず、微妙に差異がある場合があります。 では、不具合などのFixを確実に適用したい場合はどうしたらよいでしょうか。 目的のFixが含まれているかを確認する方法 目的のFixが含まれていることを確認するもっとも簡単な方法は、VxRailのRelease Noteを見ることです。 重要なSecurity FixなどはReleaseNoteに記載されていることが多いため、容易に確認が可能です。 ただしすべてのFixがReleaseNoteに記載されるわけではありませんので、記載のないものについては個別に確認する必要があります。 ESXiのImageはZipで固められているので、その中身をみて個別のFixが入っていることを確認するのが一番確実です。 具体的な手順 ここでは、以下で報告されているSecurity FixがVxRail 4.7.510に含まれているかどうかを確認する手順を例にとって説明します。 DSA-2020-118: Dell EMC VxRail Appliance Security Update for Third Party Component Vulnerability in VMware ESXi https://support.emc.com/kb/543403 VMSA-2020-0008 https://www.vmware.com/security/advisories/VMSA-2020-0008.html 上記のFixはVxRailのReleaseNoteを見るとVxRail 4.7.510に含まれている旨の記載があります。 Release-Notes 4.7 https://support.emc.com/docu91467_VxRail-Appliance-Software-4.7.x-Release-Notes.pdf 本当に含まれているかを、VxRailのUpgradeファイル内のESXi Imageを展開して確認してみましょう。 VMSA-2020-0008 によると、ESXi 6.7でのFixed Versionは、ESXi670-202004103-SG だとあります。 My VMwareのProduct Patchから、このFixはESXi670-202004002 に含まれていることがわかります。 ESXi670-202004002のリリースノートを見てみると以下の記載があります。 つまり、VMware_bootbank_esx-ui_1.33.7-15803439のVIBがVxRail 4.7.510のESXi Imageに含まれていればよい、ということになります。 では、実際にVxRail 4.7.510のUpgradeファイルをダウンロードして中身を確認しましょう。 https://dl.dell.com/downloads/DL98593_VxRail-4.7.510-Composite-Upgrade-Package-for-4.7.x.zip こちらのZIPを確認すると、以下のようなディレクトリ構造が見えますので、bundles → ESXi-xxx.zip と辿ってESXi Imageを入手します。 このESXi-xxx.zipを解凍するとさらにディレクトリ構造がありますので、metadata.zipをさらに解凍します。 metadata.zipに含まれる、vmware.xmlファイルを開きます。 このファイルの中で先ほど調べたVIB(VMware_bootbank_esx-ui_1.33.7-15803439)を検索します。 対象のVIBが確認できましたのでこのVersionには問題なくFixが含まれていることを確認できました。

ひきつづき、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。 これまでは、前提環境をととのえるための準備でしたが、 今回は、Supervisor Cluster を有効化します。 前回の投稿はこちら。 vSphere with Kubernetes ラボ環境構築。Part-09: Tier-0 ゲートウェイ作成編 なお、この投稿は vSphere 7.0 むけです。 vSphere 7.0 U1 では、下記のように少し変更があります。 vSphere 7.0 と 7.0 U1 での「ワークロード管理」有効化の違いについて。（NSX-T あり編） Supervisor Cluster の有効化。 Supervisor Cluster は、vSphere Client の「ワークロード管理」から有効化します。 （むしろ「ワークロード管理」を有効化します） vSphere Client で、「ワークロード管理」メニューを開きます。 「ワークロード管理」で、「有効化」をクリックします。 これまでの準備により「互換性あり」に vSphere Cluster が表示されるはずなので、 「wcp-cluster-01」を選択して「次へ」をクリックします。 制御プレーンのサイズ（Supervisor Control Plane VM のスペック）を選択します。 今回はハードウェア リソースの都合上「極小」を選択しています。 ネットワークの設定をします。 管理ネットワークは、次のようなパラメータを入力しています。 ネットワーク： DPortGroup-labmgmt-0010 vCenter などと通信できる、管理ネットワークのポートグループを指定する。 Supervisor Control Plane VM の 1つめの vNIC に割り当てられる。 開始 IP アドレス： 192.168.10.51 Supervisor Control Plane VM に付与される IP アドレス。 開始 IP アドレスから 5つ消費する。 Supervisor Control Plane VM の Floating IP アドレス。（1つ。開始 IP アドレスが使用される） Supervisor Control Plane VM 3台の IP アドレス。3つ。今回は .52 ～ .54） アップグレード時の予約。（1つ。今回は .55） サブネットマスク： 255.255.255.0（「開始 IP アドレス」のネットワークでのサブネット マスク） ゲートウェイ： 192.168.10.1（「開始 IP アドレス」のネットワークでのサブネット マスク） DNS サーバ： （カンマ区切りで DNS サーバを指定） DNS 検索ドメイン： go-lab.jp NTP サーバ： （カンマ区切りで DNS サーバを指定） 下にスクロールし、 ワークロード ネットワークは、次のようなパラメータを入力しています。 vSphere Distributed Switch： DSwitch Edge クラスタ： edge-cluster-01 API サーバのエンドポイント FQDN： lab-wcp-01.go-lab.jp Supervisor Control Plane VM の Floating IP にアクセスすると、 ここで指定した名前が証明書 Subject Alternative Name に設定されていたりする。 DNS サーバ： （カンマ区切りで DNS サーバを指定） ポッド CIDR： 10.244.0.0/21（デフォルトのまま） Pod のネットワークが、このレンジから払い出される。 サービス CIDR： 10.96.0.0/24（デフォルトのまま） Kubernetes 内部通信の ClusterIP で利用される。 入力方向 CIDR：192.168.70.32/27 Tier-0 ゲートウェイの外部インターフェイス（Edge のアップリンク）と同セグメントから、/27 以上のレンジを指定する。 NSX ロードバランサによる VIP に払い出される。 Supervisor Control Plane VM の VIP は、この CIDR の最初の IP アドレス（192.168.70.33）になる。 出力方向 CIDR： 192.168.70.64/27 Tier-0 ゲートウェイの外部インターフェイス（Edge のアップリンク）と同セグメントから、/27 以上のレンジを指定する。 NSX では Tier-1 ゲートウェイの SNAT アドレスとして利用される。 ストレージでは、下記の 3つのデータストアを指定するため、 仮想マシン ストレージ ポリシーを指定します。 ここでは、以前の投稿で作成した「vm-storage-policy-wcp」を指定しています。 制御プレーン ノード（Supervisor Control Plane VM の VMDK を配置するデータストア） 短期ディスク（vSphere Pod で利用するデータストア） イメージ キャッシュ（コンテナ イメージのキャッシュ） 設定値を確認して「完了」をクリックすると、Supervisor Cluster の有効化がはじまります。 「クラスタ」タブで、構成ステータスが確認できます。 開始直後、「最近のタスク」にリモートファイルのダウンロードで 404 エラーが表示されますが、これは無視します。 Supervisor Control Plane VM が自動的にデプロイされます。 ちなみに、ESXi が 4台以上あるクラスタでも、Control Plane VM は 3台です。 有効化処理がうまくいかない場合は、vCenter に root ユーザでログインして、 まず下記のログを確認してみるとよいと思います。 ログファイル： /var/log/vmware/wcp/wcpsvc.log しばらく（数十分 ～ 数時間）待つと、「構成ステータス」が「実行中」になり、 「制御プレーン ノード」の IP アドレスが、最終的に「入力方向 CIDR」で指定したレンジの IP アドレスになります。 「現在のバージョン」には、Supervisor Cluster の Kubernetes バージョンが表示されています。 これで wcp-cluster-01 クラスタで、Supervisor Cluster の機能が有効化されました。 名前空間の作成。 「ワークロード管理」メニューの「名前空間」タブを開くと、 「名前空間の作成」が表示されるので、クリックします。 クラスタを選択して、名前空間の名前（ここでは lab-ns-01）を入力して「作成」をクリックします。 名前空間が作成されました。 「ステータス」→「CLI ツールへのリンク」にある、「開く」をクリックします。 「Kubernetes CLI Tools」という、 専用 kubectl のダウンロード ページが表示されるはずです。 これでひとまず、vSphere with Kubernetes を体験するためのラボ環境が構築できました。 このページが表示されていない場合は、Supervisor Cluster の有効化が成功していても NSX-T や物理ネットワークなどの構成がうまくできていない可能性があります。 ちなみに名前空間は、Supervisor Cluster を有効化したクラスタの右クリック →「新規名前空間」でも作成できます。 以上、vSphere 7.0 ＋ NSX-T 3.0 で Supervisor Cluster の有効化でした。 おそらくつづく。 vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。 今回は、NSX の Tier-0 ゲートウェイを作成します。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-08: NSX Edge 設定編 ここでは、Supervisor Cluster を有効化する前提として必要な NSX-T によるネットワークを作成しておきます。 VLAN セグメントの作成。 Tier-0 ゲートウェイのアップリンク インターフェースを接続する VLAN セグメントを作成しておきます。 これは、NSX Edge から NSX 外部のネットワークに接続する VLAN になります。 NSX Manager にログインして、 「ネットワーク」→「接続」→「セグメント」を開きます。 「セグメント」タブの「セグメントの追加」をクリックして、パラメータを入力していきます。 パラメータは、今回のラボ環境にわせて下記のようにしています。 セグメント名： seg-vlan0070 接続： なし（デフォルトのまま） トランスポート ゾーン： nsx-vlan-transportzone VLAN： 70 少し下にスクロールして、「保存」をクリックします。 「この Segment の設定を続行しますか？」を「いいえ」で抜けると、 VLAN セグメントが作成されたことが確認できます。 Tier-0 ゲートウェイの作成。 「ネットワーク」→「接続」→「Tier-0 ゲートウェイ」を開き、 「ゲートウェイの追加」→「Tier-0」をクリックします。 つぎのようにパラメータを入力して、「保存」をクリックします。 Tier-0 ゲートウェイの名前： t0gw-01 HA モード： アクティブ/スタンバイ Edge クラスタ： edge-cluster-01 「この Tier-0 ゲートウェイの設定を続行しますか？」では、 「はい」を選択して、つづけてインターフェースの追加を実施します。 Edge の外部インターフェイスの追加。 NSX Edge のアップリンクにあたる、「外部インターフェイス」を作成します。 「インターフェイス」→「設定」をクリックします。 「インターフェイスの追加」をクリックし、パラメータを入力してから「保存」をクリックします。 名前： if-uplink-01 タイプ： 外部（デフォルトのまま） IP アドレス/マスク： 192.168.70.2/24 接続先： seg-vlan0070 Edge ノード： lab-nsx-edge-31 インターフェイスが作成されたこと確認して、「閉じる」をクリックします。 スタティック ルートの設定。 このラボでは、ルーティング プロトコル（BGP）を利用していないので、 NSX 外部のネットワークと Edge のアップリンク ネットワーク （この直前に作成したインターフェイスの接続されているネットワーク）とでルーティングが必要になります。 そこで、今回はスタティック ルート設定しています。 まだ編集途中の Tier-0 ゲートウェイの画面で 「ルーティング」→「スタティック ルート」のとなりの「設定」をクリックします。 「スタティック ルートの追加」をクリックして、 次のようなパラメータを入力して「ネクスト ホップの設定」をクリックします。 名前： default-route ネットワーク： 0.0.0.0/0 「ネクスト ホップの追加」をクリックして、 IP アドレスを入力（このラボ環境では 192.168.70.1）入力してから 「追加」→「適用」をクリックして閉じます。 「ホップ数: 1」と表示されたことを確認してから、 「保存」→「閉じる」をクリックします。 スタティック ルートに「1」と表示されたことを確認して、 「編集を終了」をクリックします。 Edge のアップリンク インターフェイスへの疎通確認。 これで、NSX-T の Tier-0 ゲートウェイとそのアップリンク インターフェイスが作成できたので、 直近で作成したインターフェイス（192.168.70.2）の疎通確認をしておきます。 たとえば、最終的に Kubernetes 環境を構築したあとで、 kubectl（kubernetes のクライアント ツール）を実行する想定の端末から ping 確認などをしておきます。 つづく！ vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。 今回は、前回デプロイした NSX Edge を、トランスポート ノードとして設定します。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-07: NSX Edge デプロイ編 Edge 用 アップリンク プロファイルの作成。 NSX Edge は、以前に設定した ESXi とは NIC 数やチーミング ポリシー、 TEP の接続するネットワーク（VLAN ID）が異なったりするので、 別のアップリンク プロファイルを追加作成します。 ※ただし、今回の構成では ESXi の TEP / Edge の TEP 両方が 同じ VLAN です。 NSX Manager にログインして、 「システム」→「設定」→「ファブリック」→「プロファイル」を開きます。 そして、「アップリンク プロファイル」タブの「追加」から、 「アップリンク プロファイルの作成」を開いて、設定値を入力していきます。 アップリンク プロファイルの名前は「uplink-profile-edge」にしています。 そのまま下にスクロールして、「デフォルトのチーミング」に、アップリンクの名前を入力します。 アクティブ アップリンク： uplink-1 スタンバイ アップリンク： 空欄のまま（Edge VM は、仮想スイッチ / ポートグループ側でのチーミングとなるので） のこりは、次のような設定にしています。 トランスポート VLAN： 71 MTU： 空欄のまま。（vDS 側で設定するため） Edge 用のアップリンク プロファイルが作成されました。 Edge トランスポート ノードの設定。 NSX Edge の、トランスポート ノードとしての設定をすすめます。 「システム」→「設定」→「ファブリック」→「ノード」→「Edge トランスポート ノード」を開きます。 デプロイずみの NSX Edge（lab-nsx-edge-31）の「NSX の設定」をクリックします。 「Edge トランスポート ノードの編集」で、 「ノード スイッチの作成」についてパラメータを入力していきます。 Edge スイッチ名： （デフォルトのまま）nvds1 トランスポート ゾーン： nsx-overlay-transportzone、nsx-vlan-transportzone （ESXi とは異なり、オーバーレイ と VLAN 両方のトランスポート ゾーンを選択します） 少し下にスクロールし、次のように入力して「保存」をクリックします。 アップリンク プロファイル： uplink-profile-edge IP の割り当て： IP プールを使用 IP プール： ip-pool-tep チーミング ポリシー スイッチ マッピング → uplink-1： fp-eth0 （Edge VM の 2つめの vNIC にあたります） 少し待って、画面下の「更新」をクリックすると、 設定の状態が「成功」になるはずです。 Edge クラスタの作成。 NSX の Edge トランスポート ノードは、「Edge クラスタ」単位で管理します。 通常は複数台の Edge トランスポート ノードを用意して Edge クラスタを構成します。 このラボは、ハードウェア リソースの都合もあり 1台だけです。 しかし NSX-T では、 Edge クラスタを構成する必要があるので、 Edge トランスポート ノードが 1台だけの Edge クラスタを作成しておきます。 「システム」→「設定」→「ファブリック」→「ノード」→「Edge クラスタ」を開きます。 「追加」をクリックして「Edge クラスタの追加」を開き、 次のようにパラメータを入力して、「追加」をクリックします。 名前： edge-cluster-01 Edge クラスタ プロファイル： デフォルトのまま トランスポート ノード： デフォルトのまま 選択済み： lab-nsx-edge-31（対象の Edge ノードを選択して「>」ボタンで移動する） これで、Edge クラスタが作成されます。 まだまだ続く。 vSphere with Kubernetes ラボ環境構築。Part-09: Tier-0 ゲートウェイ作成編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。 今回は、NSX Edge の仮想アプライアンスをデプロイします。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-06: ホスト トランスポート ノード準備編 NSX Manager に登録されている（コンピュート マネージャになっている）vCenter配下の ESXi 上であれば、 NSX Edge は NSX Manager の Web UI からデプロイできます。 しかし、このラボではハードウェア リソースの都合上、 NSX Edge を、コンピュート マネージャ vCenter 管理外の ESXi にデプロイします。 そのため、一般的な vCenter の機能（OVF テンプレートのデプロイ）で NSX Edge の仮想アプライアンスをデプロイします。 NSX Edge が NSX Manager と連携するためのパラメータも手入力します。 NSX Manager の証明書サムプリント取得。 NSX Edge の OVA ファイルをデプロイする際に、 NSX Manager の証明書サムプリントを入力する必要があります。 そこで、あらかじめ NSX Manager の Web UI で確認しておきます。 NSX Manager にログインして、 「システム」→「設定」→「アプライアンス」を開き、 NSX Manager（ここでは 192.168.10.23）の「詳細」をクリックします。 「証明書サムプリント」の横にあるアイコンをクリックすると、 「コピーしました」と表示され、クリップボードに証明書サムプリント（64文字）がコピーされます。 あとでこの文字列が必要になるので、テキスト ファイルなどに（Ctrl + v などで貼り付けて）保存しておきます。 ちなみに、この証明書サムプリントは、NSX Manager に SSH ログインして 下記コマンドで取得することもできます。 get certificate api thumbprint NSX Edge デプロイ先のポートグループ作成。 NSX Edge の仮想マシンには、Edge 内部に作成される仮想スイッチのための、 VLAN トランクポートグループが必要になります。 NSX Edge をデプロイする vSphere 環境（今回はネストの外側の環境）に、 ポートグループを作成しておきます。 このポートグループは、分散仮想スイッチ（vDS）と、標準仮想スイッチ（vSS）の、 どちらに作成しても、ラボ環境を構築できます。 今回は vSS に標準ポートグループを作成します。 まず、この vSS も NSX-T のオーバーレイ ネットワークの経路となるので、 MTU を 1600 以上に設定しておきます。 NSX Edge の管理ネットワーク用のポートグループ（ここでは pg-labmgmt-0010）を作成しておきます。 これは Edge VM の 1つめの vNIC に割り当てることになります。 アップリンク用の標準ポートグループ（名前は pg-edge-uplink）を作成します。 VLAN トランクとしたいので、VLAN ID を「すべて (4095)」としています。 ※ vDS の分散ポートグループの場合は、VLAN トランクで ID を「0 - 4094」にします。 アップリンク用の標準ポートグループは、 作成後に、無差別モードと偽装転送を「承諾」にしておきます。 このポートグループは Edge VM の 2つめ（から4つめ）の vNIC に割り当てることになります。 NSX Edge の OVA ファイルのデプロイ。 NSX Edge の OVA ファイルを、vSphere Client からデプロイします。 OVA ファイルは「nsx-edge-＜バージョン文字列＞.ova」となっています。 デプロイ先（クラスタや ESXi など）を右クリックして、 「OVF テンプレートのデプロイ」から、一般的な OVA ファイルと同様の手順でデプロイします。 ウィザードにしたがって、デプロイのフォルダやデータストアなどのパラメータを入力していきます。 （一般的な OVA ファイルのデプロイと変わらない部分は、省略しています） 「デプロイ構成の選択」では、かならず「Large」以上を選択します。 vCPU が最低でも 8以上でないと、リソース不足により Supervisor Cluster の有効化が失敗します。 ちなみに、メモリ容量はあとで削減可能です。（20GB くらいまでなら） ポートグループは、先ほど選択したものを割り当てます。 vNIC の番号（ソースネットワーク）が降順表示になっているので注意します。 「Network 0」が、1つめの vNIC です。 つぎのように割り当てます。 Network 3： pg-edge-uplink Network 2： pg-edge-uplink Network 1： pg-edge-uplink Network 0： pg-labmgmt-0010 「テンプレートのカスタマイズ」では、NSX Edge 固有のパラメータを入力します。 今回は、次のようにパラメータを入力します。 ※これ以外のパラメータは、デフォルト値のままか、空欄のままです。 ※ネットワーク関連のパラメータは、このラボのものなので環境にあわせて変更が必要です。 System Root User Password： Edge のゲスト OS にログインする、root ユーザのパスワード。 CLI “admin” User Password： Edge のゲスト OS にログインする、admin ユーザのパスワード。 Manager IP： NSX Manager の IP アドレス（今回は 192.168.10.23）。 Manager Password： NSX Manager の admin ユーザのパスワード。 Manager Thumbprint： 冒頭の手順で確認した、NSX Manager の証明書サムプリント（64文字） Hostname： lab-nsx-edge-31 Default IPv4 Gateway： 192.168.10.1 Management Network IPv4 Address： 192.168.10.41 Management Network Netmask： 255.255.255.0 DNS Server list： スペース区切りで DNS アドレス。 Domain Search List： go-lab.jp NTP Server List： スペース区切りで NTP アドレス。 Enable SSH： On Allow root SSH logins： On デプロイが完了したら、Edge VM をパワーオンします。 NSX Manager の 「システム」→「設定」→「ファブリック」→「ノード」を開きます。 そして、「Edge トランスポート ノード」にデプロイしたエッジが表示されます。 まだ NSX Edge の設定が必要な状態で、「設定の状態」には「!」マークが表示されます。 つづく・・・ vSphere with Kubernetes ラボ環境構築。Part-08: NSX Edge 設定編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。 今回は、ESXi を ホスト トランスポート ノードとして設定します。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-05: NSX Manager 設定編 今回、NSX Manager と連携する vCenter / ESXi では、すでに vDS を構成してあります。 NSX-T のオーバーレイ ネットワークでは MTU を 1600 以上にしますが、 NSX による仮想スイッチを vDS 7 に統合する場合は、MTU は vDS 側で設定します。 今回はネステッド環境なので、ネストの外側の仮想スイッチでも MTU を 1600 にしてあります。 ホスト アップリンク プロファイルの作成。 NSX Manager にログインして、 「システム」→「設定」→「ファブリック」→「プロファイル」を開きます。 そして、「アップリンク プロファイル」タブの「追加」から、 「アップリンク プロファイルの作成」を開いて、設定値を入力していきます。 アップリンク プロファイルの名前は「uplink-profile-esxi」にしています。 そのまま下にスクロールして、「デフォルトのチーミング」に、アップリンクの名前を入力します。 今回は、チーミング ポリシーが「フェイルオーバーの順序」なので、アクティブ / スタンバイです。 アクティブ アップリンク： uplink-1 スタンバイ アップリンク： uplink-2 のこりは、次のような設定にしています。 トランスポート VLAN： 71 MTU： 空欄のまま。（vDS 側で設定するため） アップリンク チーミング ポリシーが作成されました。 トランスポート ノード プロファイルの作成。 「システム」→「設定」→「ファブリック」→「プロファイル」を開きます。 そして、「トランスポート ノード プロファイル」タブの「追加」から、 「トランスポート ノード プロファイルの追加」を開いて、設定値を入力していきます。 アップリンク プロファイルの名前は「tn-profile」にしています。 少し下にスクロールし、「ノード スイッチの作成」では次のように入力しています。 タイプ： VDS モード： 標準 名前： vCenter は「lab-vc-03」、vDS は「DSwitch」を選択。 トランスポート ゾーン： nsx-overlay-transportzone （オーバーレイ トランスポート ゾーンのみ。VLAN トランスポート ゾーンは必須ではない） ふたたび下にスクロールして、残りのパラメータを入力して「追加」をクリックします。 アップリンク プロファイル： uplink-profile-esxi IP の割り当て： IP プールを使用 IP プール： ip-pool-tep チーミング ポリシー スイッチ マッピング → uplink-1： アップリンク 1 チーミング ポリシー スイッチ マッピング → uplink-2： アップリンク 2 トランスポート ノード プロファイルが作成されました。 ホスト トランスポート ノードの設定。 vSphere Cluster 単位で、ESXi にトランスポート ノード プロファイルを適用します。 「システム」→「設定」→「ファブリック」→「ノード」を開きます。 そして、「ホスト トランスポート ノード」タブの「管理元」で vCenter（ここでは lab-vc-03）を選択します。 vSphere の Cluster（ここでは wcp-cluster-01）を選択して、「NSX の設定」をクリックします。 トランスポート ノード プロファイル（tn-profile）を選択し、「適用」します。 処理の完了をしばらく待ちます。たまに「更新」をクリックて様子を見ます。 処理完了すると、「NSX 設定」が「成功」になるはずです。 vSphere Client から vDS を見ると、「NSX スイッチ」になっています。 まだつづく。 vSphere with Kubernetes ラボ環境構築。Part-07: NSX Edge デプロイ編

We taken offline VSAN cluster and re-install all hosts , here we forgot de-attached drive before re-image server. After re-image we were not able to see any nvme ssd in ESXi 6.7 , I found driver was not in vib list I installed driver on all hosts and rebooted Now I am able to see all drive but required erase partition for creating VSAN cluster , Download this driver and install by command line (VMware ESXi 6.7 intel-nvme-vmd 1.4.0.1016 NVMe Driver)

ひきつづき、vSphere with Kubernetes ラボ環境を構築していきます。 前回デプロイした NSX Manager で、設定をすすめます。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-04: NSX Manager デプロイ編 vCenter の追加。 NSX Manager に、「コンピュート マネージャ」として vCenter を登録しておきます。 （前回の図をもう一度。） NSX Manager にログインして、 「システム」→「ファブリック」→「コンピュート マネージャ」→「追加」から 「コンピュート マネージャの作成」を開きます。 今回のラボでは次のようなパラメータで追加しています。 ※下記以外はデフォルト値のままです。 名前： lab-vc-03 FQDN または IP アドレス： lab-vc-03.go-lab.jp ユーザー名： administrator@vsphere.local パスワード： administrator@vsphere.local のパスワードを入力 信頼を有効にする： はい ★これは Supervisor Cluster 有効化のために必須。 vCenter が追加されました。 接続状態が「稼働中」にならない場合は、画面下の「更新」ボタンをクリックしてみます。 「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」を開き、 管理元で vCenter（今回は lab-vc-03）を選択すると、クラスタと ESXi が表示されるようになります。 この時点では、まだ NSX は「未設定」です。 このあと、NSX のトランスポート ノードとして設定します。 トランスポート ゾーンについて。 NSX によるネットワークは、「トランスポート ゾーン」で管理されます。 これは、ESXi や NSX Edge を「トランスポート ノード」として設定する際にも指定します。 「オーバーレイ」と「VLAN」の 2種類のトランスポートが存在し、Supervisor Cluster では両方を使用します。 一般的にはそれぞれ任意の名前で追加作成すると思いますが、 このラボでは、デフォルトのものをそのまま利用します。 「システム」→「ファブリック」→「トランスポート ゾーン」を開くと、 デフォルトのトランスポート ゾーンが 2つ作成されています。 オーバーレイ トランスポート ゾーン： nsx-overlay-transportzone VLAN トランスポート ゾーン： nsx-vlan-transportzone TEP IP アドレス プールの準備。 NSX のオーバーレイ ネットワークでは、 ESXi と NSX Edge では、Geneve カプセル化プロトコルのトンネルになる、 TEP（Tunnel End Point）というポートが構成されます。 TEP のアドレス設定には、NSX の「IP アドレス プール」を使用します。 このあとの ESXi と Edge の設定に備えて、 ここで「IP アドレス プール」を作成しておきます。 「ネットワーク」→「IP 管理」→「IP アドレス プール」→「IP アドレス プール の追加」を開き、下記を入力します。 名前： ip-pool-tep そして、そのまま「サブネット」下の「設定」を開きます。 「サブネットの設定」が開くので、「サブネットの追加」→「IP 範囲」をクリックし、 パラメータを入力して「追加」をクリックします。 このラボでは、下記のパラメータにしています。 IP 範囲： 192.168.71.11-192.168.71.15 CIDR： 192.168.71.0/24 ちなみに、このラボでは ESXi の TEP と NSX Edge の TEP を同セグメント（VLAN）にしていますが、 構成によっては ESXi と NSX Edge それぞれに別セグメント（VLAN）にする必要があります。 その場合は、ちゃんと「ゲートウェイ IP」の入力も必要です。 また、NSX Edge の TEP では IP アドレス プールを使用せず、 手入力でアドレス設定すること（実際の設定値は「固定 IP のリストを使用」）も可能です。 入力したら、画面にしたがって「適用」・・・ 「保存」をクリックします。 IP アドレス プールが作成されました。 ここでも「状態」が「成功」にならない場合は、 「状態」（図だと成功のとなり）か、画面下の更新ボタンをクリックしてみます。 まだ続く。 vSphere with Kubernetes ラボ環境構築。Part-06: ホスト トランスポート ノード準備編

ひきつづき、vSphere with Kubernetes ラボ環境を構築していきます。 今回は、NSX Manager のデプロイについてです。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編 Supervisor Cluster の有効化には、NSX-T での事前準備も必要です。 下図（以前に掲載した図の流用ですが）の、赤破線あたりです。 まず、NSX-T のセットアップとしては、次のような作業が必要です。 （厳密には、もうすこし作業が分割されます） NSX Manager のデプロイと vCenter の登録。 ESXi を、NSX が利用可能な「ホスト トランスポート ノード」にする。 NSX Edge のデプロイして、「Edge トランスポート ノード」のとして準備。 NSX の Tier-0 Gateway と、そのアップリンクの作成。 vSphere / NSX 以外にも準備するものがありますが、今回は省略しています。 実際には下記のような準備が必要です。 時刻同期のため、NTP サーバ。 DNS サーバ。vCenter / ESXi / NSX などの正引き（A）、逆引き（PTR）レコードを登録しておく。 当然ながら物理ネットワークの準備も必要。（MTU 設定や、VLAN、ルーティングなど・・・） 一方で、上の図中の「Supervisor Control Plane VM」や、 それ以下のネットワーク要素のほとんどは、vSphere with Kubernetes の機能から自動管理されます。 Tier-0 Gateway と、そのアップリンク（図では t0-uplink）、VLAN 論理セグメントのみを作成しておくと、 それ以外のオーバーレイ ネットワークやロードバランサは、Supervisor Cluster の有効化などによって自動作成されます。 それでは、NSX Manager をデプロイします。 NSX-T 3.0 評価版の入手。 NSX-T 評価版のソフトウェア（.ova ファイル）と、ライセンス キーは、下記のサイトから入手できます。 VMware NSX-T Product Evaluation Center https://my.vmware.com/web/vmware/evalcenter?p=nsx-t-eval NSX Manager のデプロイ。 今回は、ハードウェア リソースの都合上、 NSX Manager は、Supervisor Cluster にするネステッド vSphere の外側にデプロイします。 デプロイ先を右クリック →「OVF テンプレートのデプロイ」から、 NSX Manager の OVA ファイルをデプロイします。 NSX Manager の OVA ファイル名は、「nsx-unified-appliance-＜バージョン文字列＞.ova」となっています。 これは Unified Appliance と呼ばれ、デプロイの途中のロール指定によって NSX Manager になります。 OVA のデプロイでは、つぎのようなパラメータ（NSX 固有でないものは記載省略）を指定します。 ※特に記載のないパラメータは、デフォルト値（もしくは空欄のまま）です。 ※ネットワーク構成は、おおよそ冒頭のイメージ図のようにしています。 仮想マシン名： lab-nsx-03 フォルダの選択： （ここの指定はネスト外側の vSphere 環境） コンピューティング リソースの選択： （ここの指定はネスト外側の vSphere 環境） デプロイ構成の選択： Small（4 vCPU, 16GB RAM） ストレージの選択： （ここの指定はネスト外側の vSphere 環境） ネットワークの選択： vCenter / ESXi と通信可能なポートグループを選択。 System Root User Password： NSX Manager の OS（VM コンソールや SSH）に root ログインするパスワードを入力。 CLI “admin” User Password： NSX Manager の Web インターフェースや OS に admin ログインするパスワードを入力。 CLI “audit” User Password： 空欄のまま。 Hostname： lab-nsx-03 Rolename： NSX Manager NSX Site Name： 空欄のまま。 Default IPv4 Gateway： 192.168.10.1 Management Network IPv4 Address： 192.168.10.23 Management Network Netmask： 255.255.255.0 DNS Server list： ラボ環境の DNS を入力。（スペース区切り） Doman Search List： go-lab.jp NTP Server list： ラボ環境の DNS を入力。（スペース区切り） Enable SSH: On Allow root SSH logins： On 補足として・・・ 「デプロイ構成の選択」はデフォルト値が「Medium」ですが、 「Small」でもラボ構築は可能です。 OVA ファイルのデプロイが完了したら、VM をパワーオンします。 しばらく待つと、Web ブラウザから https できるようになります。 そして、admin ユーザ / デプロイ時指定のパスワード でログインできるはずです。 NSX 評価ライセンスの追加。 Tier-0 ゲートウェイなどを作成するために、評価ライセンスの追加が必要です。 「システム」→「ライセンス」→「追加」から、ライセンス キーを入力しておきます。 ※ちなみに、画面上部にある青メッセージの「ライセンスの管理」でもこの画面を開けます。 つづく。 vSphere with Kubernetes ラボ環境構築。Part-05: NSX Manager 設定編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。 前回の投稿はこちら。 vSphere with Kubernetes ラボ環境構築。Part-02: vSphere 事前準備編 今回は、vSphere with Kubernetes にかかわる機能が ESXi のデータストアを選択するときに利用する、 「仮想マシン ストレージ ポリシー」の作成です。 たとえば、Supervisor Cluster を有効化する際に、データストア指定のかわりに、 仮想マシン ストレージ ポリシーを選択します。 ※これは、後程実施する手順のものです。 具体的には、下記のような作業をします。 vSphere の機能で「タグ」を作成。 データストアにタグを付与する。 タグをもとにデータストアを選択する、仮想マシン ストレージ ポリシーを作成。 ただし、vSAN データストアを利用する場合は、デフォルトで作成される「vSAN Default Storage Policy」でラボ構築をすすめられるので、次の投稿にスキップしても大丈夫です。 今回のラボでは vSAN ではなく、NFS データストアを利用するため、仮想マシン ストレージ ポリシーの追加作成をしています。 vSphere の「タグ」作成。 「タグとカスタム属性」メニューを開きます。 「タグ」画面にある「新規」リンクから、「タグの作成」画面をひらいて、 「新しいカテゴリの作成」をクリックします。 下記のようにカテゴリを作成します。 カテゴリ名： datastore-category オブジェクトあたりのタグ数： 1つのタグ 関連付け可能なオブジェクト タイプ： 「データストア」のみチェック On にする。 「タグの作成」画面にもどり、下記のようなタグを作成します。 名前： wcp-demo カテゴリ： datastore-category （直前に作成したカテゴリを選択している） タグが作成されました。 データストアへのタグ割り当て。 データストアの「サマリー」画面で、「割り当て」をクリックします。 直前の手順で作成したタグを選択します。 データストアに、タグが割り当てられました。 仮想マシン ストレージ ポリシーの作成。 「ポリシーおよびプロファイル」メニューを開きます。 「仮想マシン ストレージ ポリシー」にある、 「仮想マシン ストレージ ポリシーの作成」をクリックします。 仮想マシン ストレージ ポリシー名を入力します。 今回は「vm-storage-policy-wcp」にしています。 「データストア 固有のルール」で、「タグ ベースの配置ルールを有効化」を On にします。 ルール1 には、先ほど作成した  カテゴリ／タグ を指定します。 タグ カテゴリ： datastore-category 使用量オプション： 以下のタグ付けをされたストレージを使用 タグ： 「wcp-demo」が指定された状態にする。 「ストレージ互換性」で、タグを付与したデータストアが表示されることを確認します。 仮想マシン ストレージ ポリシーが作成されました。 続く。 vSphere with Kubernetes ラボ環境構築。Part-04: NSX Manager デプロイ編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。 今回は、vSphere 環境の事前準備です。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-01: 環境説明編 Superviser Cluster を有効化する準備として、 vSphere DRS、vSphere HA、vDS まわりの設定をしておきます。 ここから設定するのは、（前回も掲載した）サーバ構成イメージ図の赤破線の部分にあたります。 vSphere DRS の有効化。 Superviser Cluster を有効化する前提として、vSphere DRS / HA 両方の有効化が必要です。 まず、vSphere Cluster で、DRS を「完全自動化」で有効化しておきます。 vSphere Cluster を作成した時点では DRS が無効なので、「編集」から設定変更します。 vSphere DRS を有効（緑）にして、自動化レベルは「完全自動化」を選択しておきます。 vSphere HA の有効化。 そして、vSphere Cluster で、HA も有効化しておきます。 ※vSAN を利用する場合は、vSAN データストアを構成したあとで HA を有効化します。 vSphere HA も、vSphere Cluster 作成時点では無効なので、「編集」から有効化しておきます。 「障害および対応」タブで、vSphere HA を有効（緑）にしてきます。 今回のラボ構成だと共有データストアが 1つだけ（2つ以上ではない）です。 そこで、vSphere HA のハートビート データストア不足メッセージの抑止のために、「詳細オプション」タブで次のパラメータを追加しておきます。 das.ignoreinsufficienthbdatastore = true ※ 参考： vSphere HA の詳細オプション もしくは、2つ以上のデータストアを用意しておきます。 vSAN の場合は、データストアが 1つでも特にメッセージは表示されません。 vSphere Cluster で、DRS / HA 両方が有効な状態になりました。 vDS 作成 ／ ESXi のアップリンク接続。 Superviser Cluster の Kubernetes ネットワーク機能では、NSX-T 3.0 を利用します。 そして、NSX-T の仮想スイッチでは、vSphere 7.0 の分散仮想スイッチ（vDS 7）を利用することになります。 そのため、バージョン 7 の vDS を作成し、そのアップリンクに ESXi の vmnic（物理 NIC にあたる）を割り当てておきます。 ただし、今回は、vDS 作成についてこまかい手順は省略し、ポイントだけ記載しておきます。 vDS 作成時に、バージョンは「7.0.0」を選択します。 vDS の MTU はデフォルトでは 1500 です。 NSX-T のオーバーレイ ネットワークの要件にあわせて、1600 以上にしておきます。 ESXi ホストを vDS に追加して、アップリンクを割り当てておきます。 Superviser Control Plane VM 用 分散ポートグループ作成。 ※既存仮想スイッチに管理ネットワークに接続できるポートグループがある場合は不要ですが・・・ あとで Superviser Cluster を有効化する際に、 Superviser Control Plane VM を接続するネットワーク（ポートグループ）を選択することになります。 vCenter などが接続された管理ネットワークにアクセスできる、 もしくは管理ネットワーク自体の分散ポートグループも作成しておきます。 今回は「DPortGroup-labmgmt」というポートグループを作成しています。 つづく・・・ vSphere with Kubernetes ラボ環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編

vSphere 7.0 から、vSphere で Kubernetes ワークロードを実行する機能が追加されました。 vSphere with Kubernetesの設定と管理 vSphere with Kubernetes Configuration and Management （英語の原文） この機能を「ちゃんとサポートされた構成」で構築するには、 ハードウェア／ソフトウェア要件がわりと厳しめです。 そこで今回は、とりあえず機能を体験するためのラボ環境構築をしてみます。 vSphere with Kubernetes を有効化したクラスタは Superviser Cluster や、Workload Control Plane（WCP）と呼ばれていて、 vCenter のインベントリで「名前空間（Namespace）」が作成できるようになります。 この環境での Kubernetes ワークロード実行には、主に 2パターンあります。 vSphere Pod ESXi が Kubernetes の Worker Node になる。 Pod が作成されるたびに、Pod 専用の VM が起動される。 Tanzu Kubernetes Cluster ゲスト OS での Kubernetes クラスタを構成する。つまり VM が Kubernetes の Worker Node になる。 Pod は、Worker Node の VM 上で起動される。（vSphere Client から見えるのは Wroker Node まで） vSphere Client から見ると、それぞれ下記のように見えます。 環境説明。 Superviser Cluster での Kubernetes は、NSX-T の利用を前提としています。 これから構築するラボ環境のネットワーク構成は、下記のような感じになります。 NSX-T では、Tier-0 Gateway を手作業で作成しておく必要があります。 （NSX の各要素の設定については、のちほど説明するつもり・・・） サーバ構成。 今回は、下記のようなサーバ構成にしています。 図の赤破線内の VM は、あらかじめ用意しておきます。 物理マシンは、サーバではなく、ちょっと性能がいい PC を利用します。 ネステッド ハイパーバイザ環境です。（ESXi 上の VM に、ゲスト OS として ESXi をインストール） 頑張れば、もう少し CPU / メモリ リソースは削減できます。 vCPU / vRAM 割り当てが大きい vCenter、NSX Manager、NSX Edge は、ネステッド ESXi の外側に配置。 Superviser Cluster ラボ環境むけに、新規で vCenter を用意して、 ネステッド ESXi を登録しています。 ネストの内側の環境について。 まず、今回 Supervisor Cluster にする vSphere 環境です。 ESXi 3ノードの vSphere クラスタ（wcp-cluster-01）を構成しています。 バージョンは下記です。 vCenter Server 7.0.0a ESXi 7.0 GA ESXi の共有データストアは NFS です。 一般的には vSAN になると思いますが、ネステッド環境のスペックの都合上 NFS にしています。 シン プロビジョニングになるので、搭載 VM の VMDK 合計よりも少ない容量（500 GB程度）です。 ESXi には、「ワークロード管理」の機能をもつライセンスが必要です。 今回は、ESXi インストール直後の評価モード（60日間の）です。 ネストの外側の環境について。 ここまでに紹介した「ネステッド vSphere」の外側の vSphere です。 機能上ネステッド ESXi 上にのせる必要がない VM は、あえて外側の vSphere に配置しています。 下記の VM が稼働しています。 ESXi の VM が 3つ vCenter NSX Manager NSX Edge （スクリーンショットにはまだ存在しない） NFS データストアにしている Linux VM ネステッド ESXi（ESXi をインストールしている VM）の vNIC では、ネストむけのポートグループを割り当てます。 この環境では vDS を利用しており、分散ポートグループは次のように設定しておきます。 VLAN トランク（0-4094）。※vSS の標準ポートグループの場合は VLAN 4095。 無差別モード、MAC アドレス変更、偽装転送を「承諾」。 また、この vDS も NSX-T オーバーレイ ネットワークの経路になるので、 MTU を 1600 に設定しておきます。 つづく。 vSphere with Kubernetes 環境構築。Part-02: vSphere 事前準備編