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.
- If you choose to BYO Network for your Azure account, please ensure you have the requirements listed under that section.
- Before proceeding, ensure that the following Resource Providers are registered in your Azure subscription:
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.
Click the link for more information on Azure service limits.
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¶
Each IaaS provider has a unique naming scheme for their instance types. Azure breaks down their instance types by vCPU cores. More information about Windows virtual machines in Azure can be found in their official Azure documentation.
Refer to the table on our pricing page for a list of Azure instances that you can use with Frame. Note that since you are bringing your own Azure account, your pricing may be different from that shown in the table.
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.
Promotional instances provided by Microsoft by default are not currently supported by the Frame platform. If you wish to use an account with an existing promotion, you will need to either exhaust promotional hours first or contact Azure support to remove those instances.
Organizations leveraging Azure with their Xi Frame subscription can now create new accounts in a pre-existing subnet that has already been configured with their network architecture and requirements. They also have the ability to change the subnet in which an account has been created. Organizations must simply ensure they have met the requirements detailed below.
BYO Network Requirements¶
Please ensure you have met all the requirements detailed below before proceeding:
- Ample available address space for the expected number of production VMs you plan on using. You will want at least double the amount of IPs plus enough IPs to accommodate for your Sandbox and Utility Server instances.
- A security group attached to your subnet.
- If private networking is not enabled, the security group must have permissive for inbound traffic from these sources, which is crucial for Nutanix Frame backplane to be able to communicate with the virtual machines. Granted, these hosts should be accessible by the virtual machines.
- Protocol: TCP; Source: 220.127.116.11; Port: 8112
- Protocol: TCP; Source: 18.104.22.168; Port: 8112
- Protocol: TCP; Source: 22.214.171.124; Port: 8112
- Opening a Frame session requires an HTTPS connection to the VMs. You might want to customize the source from which this can be accomplished, but in a general case you would want to do this from any location. A security rule should enable this:
- Protocol: TCP; Source: Any; Port: 443
Your security rules should look like this:
Frame does not have the ability to edit the supplied network or subnet in any way when creating, using, or terminating the account. At no point does Frame alter or validate the security rules or create subnets. When an account is terminated, subnets and security rules remain untouched by our service.
To use this feature, you will want to check the box next to “Customize VPC settings.” A new field will appear, click “Enter Private VPC ID” and input the subnet path when creating an account in the following format:
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” and “Directory (tenant) ID.” These IDs are two 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 ellipsis listed next to the organization or customer you wish to add your cloud account to, click “Edit.”
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:
- Name: Enter the desired name for your BYO Cloud Account.
- 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.
- Verify Azure credentials: Click this button to verify that your credentials are valid before creating the cloud account.
- Select data centers: Select at least one data center you would like to provision your Xi Frame account(s) and resources in.
Click the check box once you have read through the disclaimer, and then click “Create.”
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.
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.
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.