Release 22.09 is a major version extended by service packs 22.09.1, 22.09.2 and 22.09.3, that include new features, scalability, security and usability improvements, and bug fixes.
The following section will breakdown the additions and updates to the Zadara Compute Cloud platform (zCompute).
Large Cluster Systems (LCS)¶
With this version of Zadara zCompute, Zadara takes a leap into new use cases that require much larger clusters at the Edge. To support larger applications, especially data analytics, a new deployment topology was added that allows for 75 physical nodes and upwards (exact numbers to be published in the future). Until now, the maximum official cluster size was 16 nodes, with engineering exceptions for specific customers to extend to 24 nodes. This is referred to as the standard configuration.
Any standard configuration cluster can be transformed into an LCS.
The transition from an LCS back into a standard configuration is not supported.
Moving to an LCS cluster requires a minimal cluster size of 16 nodes, and three additional nodes that serve as control nodes. Control nodes can’t be used to run instances. This has an impact on the floor, but not on the instance pricing. Zadara’s solution architect will recommend whether to use the standard or LCS configuration per system, based on customer needs.
Distributed Virtual Switch (DVS) mode¶
Release 22.09 introduces a new simplified network model which gives our customers the ability to place virtual machines (instances) directly on a VLAN-based mode which extend to the data center switches. This is similar to other common data center virtualization solutions, (such as VMWare, HyperV, etc.).
Essentially, tenants can regard DVS mode projects as a single virtual switch with uplinks to the data center switches. Tenants see networks that are set up by the cloud admin, and when choosing to create a network interface for the VM on the network, the system automatically adds them to a VLAN-tagged port on the virtual switch.
A network in a DVS mode project represents a VLAN-tagged L2 network. The VLAN tag itself is hidden from the users. It’s the admin’s choice whether to disclose the VLAN tag ID to users via the network name or description. VMs will get a network interface with a MAC address, but without an IP. Tenants may assign an IP address manually or via a DHCP server (connected to their physical network).
Differences between VPC mode and DVS mode projects:
Cloud admin capabilities¶
Admins can create a project in DVS mode.
Admins can create a VLAN-based network providing the VLAN tags. Note that the VLAN tags provided must match the physical switches configuration in the data centers (tagged ports, etc.).
When creating a zCompute account for tenants, the default project is a VPC project. Tenants that require a DVS project must open a ticket to Zadara Support or to their MSP system admin to create a DVS project and the desired networks.
Since most of the system services and networking capabilities of zCompute depend on zCompute controlling the IP stack, these services are not available for projects in DVS mode. The following services will be disabled:
Advanced services, such as DNS, NAT Gateway, LoadBalancers, Auto-scaling groups etc.
AWS API (Terraform is not supported)
Marketplace is available, but the cloud images are not usable in DVS projects
DVS project overview¶
DVS projects have limited features and options in the tenant UI:
DVS project and network creation¶
DVS project and network creation are restricted to admins only, and are included here solely for informative and completeness purposes.
DVS - known issues¶
NK-3898: On DVS projects, users are not able to set project level tagging that later propagates to virtual machines. Workaround: Once the VM has been created, users can navigate to the VM and add the tag.
NK-4598: The DVS instance tab shows the key pair option while restoring the snapshot backup, even though key pairs are not supported in this version.
NK-4606: The DVS networks overview displays a warning message to clear the filters, even though no filter is applied. Click
Clear Filtersto display the overview.
Direct subnet external router¶
A direct subnet is an IP subnet in a VPC that spans out of a zCompute system over a VLAN to the datacenter network. Direct subnets allow communication between physical-network and VPC entities, for example, VMs within a VPC connected to a VPSA.
In many cases, the tenant may provide a data center router for VMs in the VPC, including VMs attached to the direct subnet, to access data center subnets that are not on the direct subnet.
Until now, there was a workaround that required manually creating a network interface to represent the external router, so the user can set the proper routes in the VPC route tables. Now the administrator can add the IP of the external router during the creation of the direct subnet, and the system will be able to route to this router.
The system now creates the ENI that can be used for routing rules, making it easy to add a route towards an external network using ENI.
It is important to note that even though the route seems explicit to an IP, upon update of the external router IP, the system automatically creates a new ENI with the new IP, and updates the route in the route tables.
Auto-Scaling Groups: Added missing compatibility with AWS API¶
This version supports the Cluster Autoscaler in Kubernetes setup through the zCompute Auto-Scaling Groups. Cluster Autoscaler is a tool that automatically adjusts the size of the Kubernetes cluster when one of the following conditions is true:
There are pods that failed to run in the cluster due to insufficient resources. In this case, zCompute ASG provisions a new node (zCompute VM instance), and schedules the failed pods to run on it.
There are nodes (zCompute VMs) in the cluster that have been underutilized for an extended period of time, and their pods can be placed on other existing nodes (zCompute VMs).
Cluster Autoscaler utilizes zCompute Instance Auto-Scaling Groups to manage node groups. Cluster Autoscaler typically runs as a deployment in your cluster.
LDAP self-service enhancement¶
This version supports LDAP self-service. Tenants who wish to use their LDAP to login to their account can now set up their own LDAP connection without opening a ticket to Zadara Support to do it for them.
As part of the self-service, the account now supports a “local”/”Break glass” tenant-admin that can configure and enable the LDAP connection.
All other users should come from LDAP.
LDAP users can’t add more local users or groups. Only the local tenant admin user is allowed to do so.
How to connect LDAP to your tenant account¶
Prerequisite: The system must have a route to your LDAP server. If the LDAP server is located outside of your account and the system has no access to it, contact Zadara Support for assistance.
Log into your account as tenant admin.
Click the “Identity Provider” and follow the instructions to fill in the details.
zCompute also enhanced the user lists. Now, the lists are split into tabs:
Users: list of local users.
LDAP Users: list of LDAP users.
Protect admin password change¶
Admin users won’t be able to set a new password for themselves using the
user update API. This is to prevent someone from hijacking an open
session and changing the password without knowing the old password.
If admins want to change their own password, they can use the
user change-password API, that requires them to provide the old
password in order to proceed with the change.
Disabling the VPC DNS allows direct connection to the tenant DNS¶
In a Microsoft Active Directory (AD) environment, the AD maintains the DNS and VMs cannot use the VPC DNS. With this feature, tenants can provide the AD DNS to the Windows VMs via the DHCP protocol.
When using zCompute in VPC mode with a VPC DNS service enabled, the instances are configured to access the internal VPC DNS which serves as a caching DNS for external resolvers, in addition to adding the VPC entries. In this mode, VMs can’t be auto-registered to the external DNS. This specifically impacts Windows AD environments, where virtual machines are registered to the domain DNS while joining the domain.
Until now, disabling the VPC DNS only disabled the VPC level DNS, but still provided a subnet level DNS. The only solution for Windows domain DNS was to statically configure the Windows OS to point to the domain DNS instead of the value provided by zCompute DHCP server.
Now, when disabling the VPC DNS, the name server entries added to the DHCP options will be passed directly to the VMs, so they can stop using the workaround.
UI now warns about volumes that are not connected to any VM¶
As with many other cloud services, there are many scenarios when deleting a VM that data disks are not deleted with the VM, since volumes are entities that at any given time may be detached from one instance and connected to another. Volumes can also be detached from the VM and remain in the account as long as needed.
In some cases, customers forget to delete volumes after deleting the VMs, and then are billed at the end of the month. To avoid surprises, the system now informs when there are unattached volumes, so that customers may go and delete them if they were not intentionally kept.
Possible scenarios where volumes remain unattached:
Using the APIs, and forgetting to delete the data volumes after deletion of the VMs.
Using Terraform, and Terraform encountered a failure during the teardown process.
Using the GUI to delete a VM or multiple VMs, and forgetting to delete their data volumes.
Volumes that are not connected to any VM - known issue¶
NK-4242: ‘Default volumes’ are impossible to delete. We are experiencing difficulties in deleting what appear to be “non attached volumes”. Although the UI does not show the attachment, the volumes are still attached to the host.
Enhanced remote DNS status validation¶
Until now, the validation only checked that the name server provided to the VPC DNS is responding to queries. Now there is a validation that the DNS can resolve a known destination (default is google.com).
If the provided DNS server can’t resolve this well-known address, the DNS is reported as degraded.
Enhanced remote DNS status validation - known limitations¶
The DNS status for VPCs without a valid route to an IGW will always be “Degraded” when the default DHCP option with the google DNS is used.
If tenants set their own name server in the VPC’s DHCP options, and their name server is unreachable via the VPC gateway or it can’t resolve google.com, the VPC state will degrade.
Ubuntu 22.04 LTS image in Marketplace¶
Release 22.09.2 provides the Ubuntu 22.04 LTS OS image for download from the zCompute Marketplace.
To download the image, in the UI go to Machine Images > Marketplace.
Enhanced support utilities¶
This release contains enhanced utilities allowing Zadara Operations to improve maintenance automation flows, time to resolution of incidents, and to take more proactive measures to prevent incidents. It is highly recommended to upgrade to this version to improve supportability.