BYO Azure Account¶
Bring Your Own Azure Subscription to Frame¶
Xi Frame provides two options for managing your Azure infrastructure. You can run the resources for your Xi Frame account on an Azure subscription owned and managed by Nutanix or on one that you own and manage yourself. When you bring your own (BYO) Azure subscription, you pay Microsoft directly for infrastructure (your VMs, storage, networking, etc.) and only pay Xi Frame for the platform services.
You may choose to have your Xi Frame accounts use infrastructure provisioned under your own BYO Azure subscription because:
- You wish to take advantage of existing billing arrangements with Azure for convenience and/or pricing. For example, your organization may already have certain Azure consumption commitments or pre-payments – you can use Frame to consume those resources on your own Azure account.
- You want to have additional administrative control over your Xi Frame workloads for more detailed monitoring and metrics.
- You want to configure other network integrations (VPN gateway) on your own Azure account.
This document assumes you already have an active Microsoft Azure account and subscription. The steps below will show you how to configure and manage a BYO Azure account to integrate with Xi Frame.
Steps at a glance:
- Set service limits for your Azure account
- Create an Azure application registration
- Add your Xi Frame BYO Azure Cloud Account Credentials
- You will need a Microsoft Azure account with a valid Azure subscription. If you don’t have one already you can create one by going to Microsoft’s website.
- Permissions to add and modify role assignments for the Azure subscription ID.
Please note that some costs may begin to accrue immediately after adding your BYO Azure Cloud Account credentials to the platform. It may take up to 24 hours for your Azure account subscription to be ready (depending on your account type).
Azure Service Limits¶
By default, a newly created Azure account will impose certain service limits on available resources. Depending on the size of the Frame workload required, you will likely need to adjust the default limits imposed on the Azure account. If these limits are set to values that are lower than what is required by the Frame platform, you can expect certain functions to either fail, or be substantially delayed. The requirements by Frame for these service limits depends on the desired workload and required resources. The recommended service limit increases include the following:
The following steps may not be necessary for smaller production environments or trial accounts.
|Compute/VM||Frame recommends setting the Azure VMs service limit to 2.2x your expected max number of instances. The additional 20% will accommodate any additional resources such as Sandboxes, Utility servers, etc.|
|Azure Managed Disks||Typically, this resource does not need to be modified. If you have any concerns about capacity, we recommend 64 GiB per instance.|
|Public IPs||By default Azure offers 1,000 public IPs per region. You will need at least 2 public IPs available per workload instance and one public IP per Sandbox/Utility Server VM.|
|VNets||Each Frame account will use one VNet.|
|GPU-backed Instances||We recommend increasing service limits for GPU-backed instances to 2.2x your expected max number of instances. The additional 20% will accommodate any additional resources such as Sandboxes, Utility servers, etc.|
More information on Azure service limits can be found here.
When requesting limit/quota increases the Azure team may ask which deployment model is used. The method used is ARM (not ASM).
Azure Instance Types¶
Azure breaks down their instance types by vCPU cores. The table below shows available instance types and their corresponding vCPU values.
|Azure VM Size||vCPU Cores|
|D1_V2||1 core per VM|
|D2_V2||2 cores per VM|
|Standard _E4_v3||4 cores per VM|
|NV6||6 cores per VM|
|NV24||24 cores per VM|
When requesting instance types, you must calculate and request limits based on the amount of CPU cores you will need per region, per instance type. For instance, if you needed two D2_V2 instances, you would need to request 4 cores (2 cores x 2 instances) for the “D Series” SKU Family in your Azure Portal. More information about requesting vCPU limit increases can be found in their official documentation.
Create an Azure Application Registration¶
This section assumes that you already have an active Azure account with a subscription dedicated to Xi Frame. At this point, you should have also set the resource limits for your subscription to levels high enough to accommodate your expected loads. To confirm your subscription, login to the Azure web portal, navigate to your subscription, and confirm that its status is “active”:
Next, you will need to create an Azure app registration for Xi Frame. The app registration is the mechanism by which you’ll give Frame access to creating and managing virtual machines and storage resources in your Azure subscription. Open the Azure Active Directory option and App registration section. From there, select “New registration” to create a new app.
You’ll see a panel titled “Register an application.” You’ll be asked for the following information:
- a valid Name: you can choose any name, but we recommend you simply call it “Frame” or “Xi Frame.”
- select your desired “Supported account types” option to specify who has access to the application.
- a Redirect URI: You can leave this optional field blank.
Click “Register” at the bottom of the panel.
A notification will appear informing you that your application has been created successfully. It should now be available in your “App registrations” list.
Next, select your new application from the list and copy or write down the “Application (client) ID.” This “Application (client) ID” is one of the four values you will need for setting up your Frame integration (note that you do NOT need the “Object ID”):
Once you have written down the Application (client) ID, navigate to the “Branding” page listed in the menu on the left side of your Azure portal.
Use the application icon shown below. Click “Save.”
Next, you’ll need to create a “Client Secret” for Xi Frame to use as a password to manage your Azure resources. Click “Certificates and secrets” under your application’s management options. Click the “New client secret” button under “Client secrets”.
You will be prompted to add a new client secret. Simply add a description and select the “Never” option under “Expires.” Click “Add.”
Please note that the app key is used by Xi Frame to manage your BYO Azure account. If your key expires, Xi Frame will no longer be able to manage your account for you and you will experience an outage. This is why we recommend selecting “Never.”
On the “Client secrets” page, copy your newly-created client secret. We will need this value later on.
The final step before integrating your BYO Azure cloud account with Xi Frame entails obtaining your Azure Subscription ID and adding owner permissions to your new application. At the top of your Azure portal, search for “Subscriptions” and click on the first option that appears.
Find the subscription that you created for Xi Frame. Copy the Subscription ID and set it aside to be used in the final steps of this guide.
Now, click on the subscription to open its properties. Click on the “Access Control (IAM)” page, and then click the “Add” button on the top of the Access Control panel. Select “Add role assignment.”
A new window will appear asking for the following information:
- Role: Select “Owner” from the drop-down menu.
- Assign access to: Select “Azure AD user, group, or service principal” option.
- Select: Select the name of your application.
Once you have configured the fields above, click “Save.”
Before moving on, ensure you have obtained the following values.
- Azure Application ID
- Azure Directory ID
- Azure Subscription ID
- Azure Client Secret
You’ll use these values for the Xi Frame setup below.
Add Frame BYO Azure Cloud Account Credentials¶
BYO cloud accounts can be created within one of two different contexts of Frame’s logical hierarchy (the “customer” or the “organization” tier). More information about Frame’s hierarchy concepts can be referenced here.
A BYO cloud account created at the “customer” (highest) tier will be accessible to all hierarchical children (“organizations” and their accounts). If you choose to add the BYO cloud account at the “organization” tier, the BYO cloud account will only be available to the chosen organization and any accounts underneath it.
Once the BYO account is created and accessible, any accounts created from that point forward will have the new BYO account available as an option for the platform. “Organizational” admins are authorized to create a new organization with BYO Azure credentials or add BYO credentials to an existing organization. “Customer” admins have the same authorizations as “organizational” admins, as well as the authorization to add BYO credentials to existing customers.
Go to the Frame Admin view.
Navigate to the “Organizations” or “Customers” section (depending on where you wish to add the cloud account).
Click on the name of the organization or customer you would like to add your cloud account to.
Select the “Cloud Accounts” tab and then select “Add Cloud Account” in the upper right corner:
A new window will appear prompting you for the information you recorded earlier:
- Application ID: Enter the Azure Application ID.
- Directory ID: Enter the Azure Directory ID.
- Secret: Enter the Azure Secret key value.
- Subscription ID: Enter the Azure Subscription ID.
- Name: Enter the desired name for your BYO Cloud Account.
- Select data centers: Select at least one data center you would like to provision your Xi Frame account(s) and resources in.
Your BYO Azure account is now available to select during the account/organization creation process. Be aware that new Xi Frame accounts on BYO Azure may take 20+ minutes to be ready after account creation.
What Resources are Created by Xi Frame under my Azure Subscription?¶
Xi Frame provisions a single storage account for every datacenter region selected upon cloud account creation. The Sandbox image (a.k.a. the “Master Workload Image”) is copied to each storage account.
If you create non-Frame related virtual machines in your AWS VPC or Azure VNET that is being managed by Frame, those virtual machines may be identified as potentially orphaned resources by Frame and deleted. We do not support the use of non-Frame resources in a Frame-managed VPC/VNET.
The total cost of your Azure service depends on your service tier with Azure and any custom pricing arrangements you may have. Full details of Azure pricing for these areas are listed in Azure’s pricing information online. If you have an Enterprise Agreement, you can download your specific price list from the EA Portal.
Frame’s default settings configure the following Azure instance types, which correspond to the Air and Pro system models:
- D1_V2 (Air 4GB - Azure)
- D2_V2 (Air 8GB - Azure)
- NV6 (Pro 56GB)
- NV24 (Pro 224GB)
Other instance types are available through a custom configuration request to Frame Support. Note that when your subscription is linked to Frame, the base images for these instances are copied to each of the Azure regions supported by Frame.
Storage sizing is based on several factors specific to your apps: the base system image of the Windows OS, the size of your applications plus application data and any user data. Additional data is consumed if you are using a Utility Server.
The base system image for the Sandbox can be set to any desired capacity upon account creation. The general formula for estimating the total amount of storage required is the Sandbox image size multiplied by the maximum number of instances multiplied by the monthly hours consumed. Total storage also includes the system image size of all Utility Servers multiplied by the number of hours consumed per month. Note that even if instances are powered off, storage is still consumed.
Your networking usage on Azure also depends on your apps and the work patterns of your users. Azure networking limits and data transfer pricing are based on inbound and outbound data sent to or from Azure regions or the internet. Typical data transfer costs for Frame customers are between 1% and 2% of their overall monthly bill. For details about how your account will be charged for data transfers, please refer to Azure documentation.
Your Azure expenses are separate from the cost of the Frame service for our BYO accounts. Azure bills your account according to your usage patterns on Frame, as described in our documentation regarding capacity management.