共用方式為

Azure Stack Validation Environment – Part 5: Putting it all together

  • 發行項

Azure Stack

Building an end-to-end validation environment

Part 5: Putting it all together

By Paul Appleby, Kath McBride, and Joel Yoker. Edited by Derek Gamlyn and RoAnn Corbisier.

Azure Customer Advisory Team (AzureCAT)

This article is Part 4 in the Azure Stack Validation Environment series:

E-Book - This series of blog posts is available as an e-book on Azure.com:

Pulling it all together

Now that we have reviewed the core capabilities and features of Azure Stack that are required to deliver services to your users, we’ll look at design decisions and then steps to building an end-to-end validation environment for your installation.

Customer scenario

In our example, we will use an imaginary enterprise customer called Contoso. Like many enterprises, Contoso contains several business units which independently operate when consuming services from IT while still adhering to corporate IT standards. Figure 23 is a diagram of the high-level organizational model for Contoso. The company has four departments: Human Resources (HR), Finance, Information Technology (IT), and Development.

Figure 23. Contoso organizational design for this example

Contoso wants to deploy their first Azure Stack scale unit as a lab environment in a single datacenter to provide each business unit access to on-premises Azure services for their applications. Contoso envisions two primary users of Azure Stack, their IT department and their departments that align to the other business units within the organization. Contoso’s departments typically require different services or quantity of resources on the Azure Stack based on their application’s needs. At Contoso, HR and Finance both have specific applications that they require, and IT and Development use standard services as they build and deploy applications into the cloud. In addition to Azure marketplace images, Contoso’s departments are required to use internally certified operating system images for the development of their applications. Operationally, Contoso has established naming conventions for resources they provision in their datacenter, so they wish to extend similar requirements to resources deployed in Azure Stack. Aside from the benefits consistent naming provides towards achieving standardization, Contoso wants to ensure that resources created in the environment are traceable by department, operating system, and application. To help drive adoption of this new service, a trial offer should be made available to each department to support an early learning experience.

As we walk thru the design decisions in the following sections, we will refer to this business scenario and explore how different capabilities can be used to address Contoso’s needs. Keep in mind that while these decisions are specific to the creation of a lab, the same considerations are required when designing your production deployments.

Design decision 1: Deployments

In our example, we will focus on the customer-owned deployment model, based on Contoso’s primary business units. It is important that we understand the department’s applications and services because they will impact our design decisions. As we move through the process of designing the solution, we also need to consider the plans and offers that will be required by each of these departments, as well as determine how regions will be utilized when this functionality becomes available. Given that Contoso has a single datacenter we’ll focus on a single region deployment of Azure Stack.

An outline of the single-region deployment applications required by each group is listed below.

Domain Business Units Applications
local.azurestack.external Human Resources Multiple websites using a MySQL backend.
Finance A single commercial off-the-shelf finance application using a backend SQL Database.
Information Technology Core IT services, no specific applications.
Development Responsible for maintenance and upgrades to the HR websites and the Finance application.Investigating the inclusion of Key Vault capabilities to new applications.

 

To provide redundancy for administration, we will also add a second administrator to the Default Provider subscription.

Region Azure Stack Operators Co-administrators
Local Admin1@"mylab".onmicrosoft.com ITAdmin1

Design decision 2: Subscriptions and naming conventions

Contoso has determined the following high-level goals when designing their subscriptions:

  • Design an enterprise strategy based on business units.
  • Local administrators will manage users and services for their business units.
  • Use a naming strategy that meets Contoso’s tracking requirements.

From a subscription perspective, Contoso will use a hybrid subscription model to support the distinct needs of their departments. HR and Finance will use a self-service subscription model publicly visible offers. In contrast, the IT and Development departments will have delegation enabled, so the subscriptions will be created for each business unit, and a delegated administrator will manage each teams’ user subscriptions.

Contoso has defined naming standards they require their users to follow and in the table below we have defined the naming for each department’s subscriptions. Based on those goals, we will use the following naming convention values which will be used in each subscription:

  • Azure Stack Cloud: CAS (“Contoso Azure Stack”)
  • Business Units:
    • Human Resources: HR
    • Finance: Fin
    • Information Technology: IT
    • Development: Dev

The following naming conventions will be used for each Azure Stack object type:

Object Type Naming Convention Example
Subscription [cloud]-[business unit]-Subscription-[optional: sequential number] CAS-IT-Subscription-01
Quota [cloud]-[resource provider or service name]- [optional: service tier] CAS-AppSvc-Premium
Plan [cloud]-[business unit]-Plan-[optional: sequential number] CAS-IT-Plan
Add-on Plan [cloud]-[resource provider or service name]-AO CAS-KeyVault-AO
Offer [cloud]-[business unit]-Offer-[optional: sequential number] CAS-IT-Offer
Tag [authorized tag name]: [authorized value] Dept : CAS-IT
Lock [object/scope]-[type]-Lock

 

Based on these goals and standards, the resulting design decisions are reflected in the following worksheet:

Business Units Subscription Name Subscription Administrator
Human Resources CAS-HR-HRAdminCAS-HR-HRuser1 HR Admin
Finance CAS-Fin-FinAdminCAS-FIN-Finuser1 Fin Admin
Information Technology CAS-IT-Subscription IT Admin
Development CAS-Dev-Subscription Dev Admin

Design decision 3: Services

To support a wide range of Azure services to each of the business units, additional resource providers will need to be deployed. We will include the following resource providers in our solution to enable provisioning of both IaaS and PaaS services to user subscriptions.

Resource Provider Default
Compute Yes
Health Yes
Network Yes
Storage Yes
Key Vault Yes
MySQL No
SQL No
App Service No

Design decision 4: Quotas, plans, and offers

For Contoso’s business units to access services, we need to create offers and plans, and align quotas to each plan. When we design our offers, we must be aware of the services required by each business unit’s applications.

First, let’s review the needs of each of Contoso’s business units. HR has some websites that use MySQL as a backend database tier. To meet their application needs, they require the AppService and MySQL resource providers, as well as compute, storage, and networking resource providers. These websites do not use a lot of resources, so we will set quotas at 50% of the defaults; this will support both current and future needs and can be increased as required. Finance, on the other hand, relies heavily on an off-the-shelf cloud-ready application that uses SQL server as its database. Like HR, their usage is not projected to be overly heavy, so we will set quotas at 50% of the defaults. To support the needs of both HR and Finance, along with the default IaaS services, we will be required to deploy the optional SQL/MySQL resource providers.

Next, we can look at the needs of Contoso’s IT and Development division. Contoso’s IT department manages all the operational tasks required for their datacenter environment, as well as consuming resources for deployment and quality testing of the company’s applications. From a quota perspective, the IT department would be permitted to consume services using the default limits of each resource provider while development is restricted to 75% of the default values. IT is also responsible for ensuring that any custom images the company requires are made available in the marketplace. The Development department develops and maintains all the applications that Contoso requires. They work closely with IT on the release of these applications across the company. Both departments require all the IaaS services, as well as the additional resource providers accessed by HR and Finance. Development is looking to enable Key Vault capabilities for business applications in the future and will require this resource provider for applications which are under development.

Base offers and plans

The following goals have been identified when designing Contoso’s offers, plans, and quotas:

  • Use an easy to follow naming standard for all offers, plans, and quotas.
  • Create separate offers, plans, and quotas for each business unit.
  • Delegate administration for non-IT users to team administrators.
  • Configure quotas so they can be adjusted on a per-team basis.

Based on these goals, the resulting design decisions are reflected in the following worksheet:

Offers Advertised /Assigned Assigned Users Plans Base Services Quota Name  Quota Limits
CAS-HR-Offer Advertised None CAS-HR-Plan ComputeNetworkStorageApp ServiceMy SQL CAS-ComputeCAS-NetworkCAS-StorageCAS-AppSvc-PremiumCAS-MySQL-Premium 50% of defaults 
CAS-Finance-Offer Advertised None CAS-FIN-Plan ComputeNetworkStorageSQL CAS-ComputeCAS-NetworkCAS-StorageCAS-SQL-Premium 50% of defaults 
CAS-IT-Offer Assigned IT1IT2IT3 CAS-IT-Plan ComputeNetworkStorage CAS-IT-ComputeCAS-IT-NetworkCAS-IT-Storage 100% of Defaults 
CAS-Dev-Offer Assigned Dev1Dev2Dev3 CAS-Dev-Plan ComputeNetworkStorageApp ServiceMy SQLSQL Key Vault CAS-Dev-ComputeCAS-Dev-NetworkCAS-Dev-StorageCAS-AppSvcCAS-MySQLCAS-SQLCAS-KeyVault 75% of Defaults
CAS-Trial-Offer Advertised None CAS-Trial-Plan ComputeNetworkStorage CAS-Trial-ComputeCAS-Trial-NetworkCAS-Trial-Storage 2 virtual machines10GB Storage4 x IP

 

Add-on plans

Add On Plans Quotas Quota Limits
SQL Plan CAS-SQL-AO CAS-SQL-Premium 
App Service Plan CAS-AppSrv-AO CAS-AppSvc-Premium
MySQL Plan CAS-MySQL-AO CAS-MySQL-Premium
Key Vault Plan CAS-KeyVault-AO Unlimited

 

To provide their business units with the operating system images Contoso requires, we will download any available images using Azure Marketplace syndication and upload any custom images to Marketplace in Azure Stack.

Design decision 5: Delegation

Contoso has determined that for their Development subscriptions, they will assign an administrator to manage users and resources. They will also use a custom URL for their delegated site.

HR and Finance, however, will rely upon the IT team to provision offers to them and manage their users. Offers for both business units will be set to public, so they are visible to all the business units, and each will select the appropriate offer.

Goals:

  • Design a naming standard that is easy to follow.
  • Business unit administrators will manage users and delegated offers.

 

Business Units Delegated Administrator Custom URL
Development Dev Admin ContosoDev

 

Design decision 6: Resource tags and locks

To support standardization of billing and the ability to trace resources back to their owners, Contoso will implement resource tags. Contoso will apply resource tags on each resource to identify business unit to enable chargeback or billing for each group and to identify any virtual machine operating system being deployed.

Resource tags associated with operating systems will be performed during provisioning. However, tagging of resources within the business units will be based upon corporate policy with the expectation users will tag their resources. Should resources without tags be found, the IT department can tag them using PowerShell.

Because there will be multiple administrators of the Azure Stack solution across the IT organization, we will use locks for all IT and Development offers to prevent accidental deletion.

Tags:

Tag Name Tag Value Tag Scope
Dept CAS-Finance All Finance resources
CAS-HR All HR resources
CAS-IT All IT resources
CAS-Dev All Development resources
Operating System WS2016 All Windows Server 2016 virtual machine resources
WS2012R2 All Windows Server 2012 R2 virtual machine resources
Application Application name Resource groups for each application

 

Locks:

Lock Name Locked Resource Lock Value
IT-Delete-Lock CAS-IT-Offer Delete
Dev-Delete-Lock CAS-Dev-Offer Delete

 

Steps to building the solution

In the preceding sections, we created several tables of information based on design decisions that represent the high-level design for this lab. We will use that information to build a solution that delivers an enterprise Azure Stack environment following these steps.

  1. Deploy the Azure Stack Development Kit.
  2. Install PowerShell for Azure Stack.
  3. Register Azure Stack against your Azure subscription.
  4. Configure additional Azure Stack operators.
  5. Download Marketplace items.
  6. Deploy and configure the App Service resource provider.
  7. Deploy the SQL and MySQL resource providers.
  8. Create services quotas, plans and offers.
  9. Import the required Azure Stack modules.
  10. Import utilities and templates.
  11. Create required delegated offers.
  12. Configure quotas.
  13. Add Marketplace items.
  14. Configure resource tags.
  15. Configure resource locks.

Completed design

Now that we have reviewed our design decisions based on our organization’s requirements, we can create the initial Azure Stack logical design. The diagram in Figure 24 shows an example of a finished solution that can be implemented as a validation environment with the Azure Stack Development Kit and in the production scale-unit deployment of Azure Stack.

Figure 24: Envisioned Contoso Azure Stack solution

Conclusion

Azure Stack extends the power of Azure to your organization’s datacenter, enabling development of hybrid solutions using Azure Services, and offering a range of new possibilities for your users’ applications and services. Like most IT solutions, you must carefully plan when implementing an Azure Stack deployment, so your users can get started developing applications quickly and easily.

In this article, we have discussed some of the key decisions you encounter around the topics of Azure subscriptions, quotas, plans, offers, and administrative role design. Next, we use these decisions to model an environment with the Azure Stack Development Kit, enabling users and developers to gain hands-on experience prior to the deployment of your first Azure Stack scale unit.

We hope this has provided you with the necessary information to help your organization get the most out of Azure Stack.

Learn more

For more information, see the following resources:

 

This article is Part 5 in the Azure Stack Validation Environment series:

 

That's the conclusion of our series! For the eBook download, see Azure Stack: Building an end-to-end validation environment.

 

Azure CAT Guidance

"Hands-on solutions, with our heads in the Cloud!"

Comments

  • Anonymous
    November 29, 2017
    UPDATE: I added the links to all five parts of this article series.