Layer 2 VPN to the Cloud – Part II

Almost 3 years ago I have published an article how to set up layer 2 VPN between on-prem vSphere environment and vCloud Director Org VDC.

As both vCloud Director and NSX evolved quite a bit since to simplify the whole set up, here comes the part II.

Let me first summarize the use case:

The tenant has an application that resides on 3 different VLAN based networks running in its own (vSphere) datacenter. The networks are routed with existing physical router. The tenant wants to extend 2 of these networks to cloud for cloud bursting or DR purposes, but not the 3rd one (for example because there runs a physical database server).

The following diagram shows the setup.

The main advancements are:

  • vCloud Director natively supports NSX L2 VPN (VCD 8.20 or newer needed).
  • NSX now (since 6.2) supports configuration of unstretched networks directly (no static routes are necessary anymore)
  • This means the full setup can be done by the tenant in self-service fashion

Here are the steps:

  • The tenant will deploy freely available NSX Standalone Edge in its datacenter connected to trunk port with 2 VLANs mapped (10 and 11). Additional network configuration is necessary (forged transmits and promiscuous mode or sink port creation – see the link)
  • In the cloud Org VDC tenant deploys two routed Org VDC networks with identical subnets and gateways as networks A and B. These networks must be connected to the Org VDC Edge GW via subinterface (there can be up to 200 such networks on single Edge). The Org VDC Edge must have advanced networking enabled.
  • Tenant enables and configures L2VPN server on its Org VDC Edge GW. Note that this is a premium feature that the service provider must enable in Organization first (see this blog post).
  • Before the L2VPN tunnel is established the following must be taken into account:
    • The Org VDC Edge GW IP addresses are identical with the on-prem existing physical router. Therefore Egress Optimization Gateway addresses must be entered in the Peer Site configuration. That will prevent the Org VDC Edge GW from sending ARP replies over the tunnel.
    • The same must be performed on the Standalone NSX Edge via CLI (see egress-optimize command here).
    • The non-stretched network (subnet C) must be configured on the Org VDC Edge GW so it knows that the subnet is reachable through the tunnel and not via its upstream interface(s). This option however is not in vCloud UI, instead vCloud networking API must be used.
      Alternatively the provider could configure non-stretched network directly in the NSX UI:
    • Finally, the tunnel can be established by configuring L2VPN server details on the on-prem Standalone NSX Edge L2VPN client (endpoint IP, port, credentials, encryption) and providing VLAN to tunnel mappings.
    • Note to find the Org VDC network subinterface tunnel mapping vCloud API must be used again:
Advertisements

vCloud Director vApp Runtime Lease Expiration Action

In vCloud Director it is possible to configure vApp leases. The maximums are set by system admin at Organization level (in Policies), which can be lowered by Org Admin (at org level) and set by vApp owner at the vApp level. A vApp has runtime lease (for how long it will be in running state) and storage lease (for how long it will consume storage once it is not running).

vApp leases are very useful in test & dev or lab environments to make sure abandoned, unused VMs are not running and taking resources.

When vApp lease is coming to an end, its owner gets a reminder via email (how many days before expiration can be configured in User Preferences) and can optionally reset vApp lease to avoid its stopping or deletion.

By default expired running vApp is put into suspended state which means its memory content is saved to datastores. This ensures fully consistent state upon consequent power on of the vApp. This however make not be always needed especially in dev/lab situations – the memory content could take lots of storage space and for example saving 16 GB RAM VM to datastore could also create IO performance impact. As of vCloud Director 8.20 the Organization Administrator can instead change the default runtime expiry action to power off. The setting is done at Org level and must be done via API by setting the element <PowerOffOnRuntimeLeaseExpiration> of OrgLeaseSettingsType to true. The API version must be at least 25.0.

PUT /api/admin/org/eea1f10c-3fee-43d7-bd8e-be63453d6e34/settings/vAppLeaseSettings

Accept:application/*+xml;version=29.0
x-vcloud-authorization:{{x-vcloud-authorization}}
Content-Type:application/vnd.vmware.admin.vAppLeaseSettings+xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VAppLeaseSettings xmlns="http://www.vmware.com/vcloud/v1.5">
    <DeleteOnStorageLeaseExpiration>true</DeleteOnStorageLeaseExpiration>
    <DeploymentLeaseSeconds>1209600</DeploymentLeaseSeconds>
    <StorageLeaseSeconds>15552000</StorageLeaseSeconds>
    <PowerOffOnRuntimeLeaseExpiration>true</PowerOffOnRuntimeLeaseExpiration>
</VAppLeaseSettings>

Note:

When the vApp expiry action is set to power off, the actual VM stop action power off (hard) vs shutdown (gracefull) procedure depends on the vApp’s config for each VM (tab Starting and Stopping VMs).

Also note that subsequent edit of Org policies in UI will reset the Org PowerOffOnRuntimeLeaseExpiration setting back to default (false).

Missing Licensing Metrics in vCloud Director 9.0

You might have noticed that vCloud Director 9.0 no longer displays licensing metrics.

This was a conscious decision as already for some time the licensing is handled externally by vCloud Usage Meter and the metering in vCloud Director caused vCloud database bloat.

If for some reason you still need to have these metrics available in UI, vCloud API or vROps Management Pack you can enable license metering with this command on a cell. No need for reboot, just wait few minutes for the next data collection.

$VCLOUD_HOME/bin/cell-management-tool manage-config -n licensing.metrics.vm.enabled -v true

How to Configure Additional VM Metrics in vCloud Director

vCloud Director already for some time (since version 5.6) provides to tenants basic set of VM metrics. Until vCloud Director 9.0 they had to be retrieved with vCloud API, however now the users can easily access the metrics from the new HTML5 UI.

vCloud Director 9.0 besides adding the metric UI also simplifies the metric database backend configuration (no KairosDB needed anymore) and also provides the option to service provider to configure additional VM metrics.

Here follows the step by step description of the last point. I assume that Cassandra cluster – the VM metric database is already set up.

  • First you need to find the metric names VC Performance Manager uses. This PowerCLI script exports all VM metric names.
  • Now we will create text file (e.g. metrics.groovy) with the new metrics.

configuration {
metric("mem.granted.average")
metric("mem.granted.maximum")
}

The metrics in the file must not overlap with the already existing default metrics. Additional options about frequency, interval averages, etc. can be provided as well. See docs for the details.

  • On a vCloud Director cell with the cell-management-tool we will import the new metrics:
    $VCLOUD_HOME/bin/cell-management-tool configure-metrics –metrics-config /tmp/metrics.groovy 
  • Still on the cell we need to update Cassandra schema, again with the cell-management-tool (provide the correct nodes addresses, DB authentication details, port and metrics time to live in days):
    $VCLOUD_HOME/bin/cell-management-tool cassandra –configure –cluster-nodes 172.16.0.41 –username cassandra –password cassandra –port 9042 –ttl 31 –update-schema
  • Restart all cells

That is all. After while we can monitor the new metrics with the UI or API.

The metric definition is stored in vCloud Director table metric_configuration.

How To Disable Local System Administrator Accounts in vCloud Director

For some time there has been a hidden security feature in vCloud Director that allows disabling local system administrator accounts. During vCloud Director installation a default local system administrator account is created. The user credentials are stored encrypted in the vCloud Director database but there is no way to enforce complex password policies other than Account Lockout Policy.

It is possible to configure external identity sources such us generic LDAP for basic authentication and SAML2 IdP (such as vCenter SSO). The authentication and thus also the password policies are than managed externally. However, when you try to delete or disable all local system administrator accounts you will get the following error:

Cannot delete or deactivate the last system administrator.

This is a built in protection against completely locking yourself out when the external identity sources are not available.

Some customers can have the need to enforce strict security rules on all vCloud Director system administrator logins. There is a non-documented way to disable all local system administrator accounts with a single command. The system administrator can run the following cell-management-tool  command to enable config property local.sysadmin.disabled.

$VCLOUD_HOME/bin/cell-management-tool manage-config -n local.sysadmin.disabled -v true

Immediately after the property is enabled, authentication with local accounts will stop working. It means authentication for all local system administrator accounts that exist in vCloud Director (not just the default account created during installation) will be rejected. Organization local accounts will not be affected.

In case access to external IdPs is lost, the system admin can again disable the property to regain access to vCloud Director:

$VCLOUD_HOME/bin/cell-management-tool manage-config -n local.sysadmin.disabled -v false