In this article, we take a look at VMware NSX-T Data Center Multisite and, more specifically, the failover/recovery procedure for an NSX-T environment spanning two sites in an active/standby deployment. This is also known as the NSX-T Multisite disaster recovery use case.
Backing up NSX-T Data Center is a simple process; however, at time of writing, automating the retention period for the backup files requires a few additional tasks and is not configurable via the NSX Manager UI. These additional steps are quick to implement and will ensure your SFTP server does not run out of storage.
By default, NSX-T transport nodes access NSX-T Manager nodes via their IP address, however, changing this behaviour so that the NSX-T Manager FQDN is used instead can be implemented easily via REST API call.
FQDN registration is an NSX-T Multisite requirement. As such, FQDN registration is not required for single-site deployments.
In the scenario whereby a customer needs to failover NSX-T operations to a secondary site (by deploying a new NSX-T Manager and restoring from backup), the NSX-T Manager(s) and Cluster VIP address will likely change unless they have implemented stretched-L2. As such, the NSX-T Manager(s)/Cluster FQDN needs to be registered with all NSX-T transport nodes, and once a new NSX-T Manager is deployed to the secondary site and restored from backup, DNS can be amended to point at the new NSX-T Manager(s)/Cluster FQDN, and management operations restored.
In NSX-T, the Admin and Audit user passwords for both the NSX Manager and NSX Edge appliances expire, by default, after 90 days. When these passwords expire, you will not be able to log in and manage your NSX-T components. This includes any API calls where administrative credentials are required.
In this article I detail the simple process of amending the expiration period or, if so required, removing the password expiration altogether (the latter being perfect for POC and/or lab environments).
Continue reading → VMware NSX-T – Modifying the Default Admin Password Expiration
Reading Time: 6 minutes
For those coming from an NSX-V background, you’ll remember how we enabled east-west traffic by deploying Distributed Logical Routers (DLR). This has changed ever so slightly in NSX-T, with earlier versions using Tier-1 Logical Routers, and in 2.4, Tier-1 Gateways.
Continue reading → VMware NSX-T Logical Routing: Part 1 – Tier-1 Gateway
Reading Time: 6 minutes
Welcome to the second article in the series detailing a migration of VMware NSX Data Center for vSphere (NSX-V) to NSX-T Data Center. In this article I focus on the preliminary checks to ensure the NSX-V environment is fit for migration.
In part 1 (VMware NSX-T Data Center Migration – Part 1 – Deploy Manager Appliance) I covered the process of deploying the NSX -T Data Center Manager Appliance, as well as a number of prerequisite tasks required to prepare the new NSX-T environment for the eventual migration (coming in part 3).
In this article I detail a number of preliminary checks within the NSX-V environment (including ESXi hosts, vSphere Distributed Switches, VXLAN configuration, VTEP, NSX Controllers, Edge Services Gateways, etc.) to ensure all is well prior to the migration process itself. Where any issues are identified, these must be resolved prior to the migration process.
Reading Time: 6 minutes
Welcome to the first in a new series of articles detailing the migration process of VMware NSX Data Center for vSphere to NSX-T Data Center. The migration to NSX-T will be split into three steps:
Note – In this article, the process of deploying the VMware NSX-T Data Center Manager Appliance can be considered the same as whether you are a) deploying into a greenfield environment void of any NSX, or b) migrating NSX Data Center for vSphere to NSX-T.
Continue reading → VMware NSX-T Data Center Migration – Part 1 – Deploy Manager Appliance
Reading Time: 3 minutes
Today saw the release of VMware NSX-T 2.4, the latest and greatest, lauded as a ‘landmark release’ for the product.
Since its initial release in February 2017, NSX-T has focused on addressing organisational requirements to support cloud-native applications, bare metal workloads, multi-hypervisor environments, and public clouds. With the release of NSX-T 2.4, we can now add multi-clouds to the list.
NSX-T delivers security to diverse endpoints such as VMs, containers, and bare metal, as well as a range of cloud platforms and cloud native projects including Kubernetes, VMware PKS, Pivotal Application Service (PAS), and Red Hat OpenShift.
With NSX-T 2.4, VMware are able to deliver further advancements in networking, security, automation, and an ‘operational simplicity for everyone’. This includes IT admins, DevOps teams, and developers. As such, NSX-T is an enabler for customers embracing cloud-native application development, expanding use of public cloud, and those who require automation to drive agility.
