Save to My DOJO
In the last article we discussed hybrid cloud scenarios and where there are the differences between private, public and hybrid clouds. We already have had a look on how cloud in general work and why you should use cloud services instead of setting up local environments, often called private clouds. In this article we’ll be diving deeper into how you can test Azure Stack yourself.
Azure Stack Refresher
With Microsoft Azure there are worldwide cloud services available within more than 50 regions and +150 datacenters, exclusively connected using the Microsoft owned backbone. But if there are scenarios where you explicitly need cloud services on-premises, Microsoft is offering Microsoft Azure Stack. This is a downsized version of Azure using the same stack of technologies that they are running in public Azure but on a smaller footprint (4-12 servers in one rack).
Azure Stack is bound to hardware, that has been tested and certified for Azure Stack. These hardware vendors are:
The typical scenarios for Azure Stack are:
- Disconnected/Edge Scenarios (e.g. running Azure Services on a ship or a plane)
- Data privacy reasons (data cannot leave the company location)
- Modern Cloud App Development on premise
As I already mentioned above, Azure Stack software and hardware must to be bought as an appliance, or so-called “integrated environment”. There is no software download for Azure Stack available with Microsoft. But for testing (PoC) purposes, it is not a good idea to order 4-12 servers and later decide, if this decision was suitable. Therefore, Microsoft offers a trial version of Azure Stack, called the “Azure Stack Development Toolkit (ASDK)”. It is not bound to any physical hardware vendor, does not provide any high availability or performance but you could download and install it yourself for test/dev scenarios.
Hardware Requirements for the Azure Stack Development Kit
The hardware requirements for an ASDK Azure Stack host are as follows:
|Disk drives: Operating System||1 OS disk with minimum of 200 GB available for system partition (SSD or HDD)||1 OS disk with minimum of 200 GB available for system partition (SSD or HDD)|
|Disk drives: General development kit data*||4 disks. Each disk provides a minimum of 140 GB of capacity (SSD or HDD). All available disks are used.||4 disks. Each disk provides a minimum of 250 GB of capacity (SSD or HDD). All available disks are used.|
|Compute: CPU||Dual-Socket: 12 Physical Cores (total)||Dual-Socket: 16 Physical Cores (total)|
|Compute: Memory||96 GB RAM||128 GB RAM (This is the minimum to support PaaS resource providers.)|
|Compute: BIOS||Hyper-V Enabled (with SLAT support)||Hyper-V Enabled (with SLAT support)|
|Network: NIC||Windows Server 2012 R2 Certification required for NIC; no specialized features required||Windows Server 2012 R2 Certification required for NIC; no specialized features required|
|HW logo certification||Certified for Windows Server 2012 R2||Certified for Windows Server 2016|
* You need more than this recommended capacity if you plan on adding many of the marketplace items from Azure.
Data disk drive configuration: All data drives must be of the same type (all SAS, all SATA, or all NVMe) and capacity. If SAS disk drives are used, the disk drives must be attached via a single path (no MPIO, multi-path support is provided).
HBA configuration options
- (Preferred) Simple HBA
- RAID HBA – Adapter must be configured in “pass-through” mode
- RAID HBA – Disks should be configured as Single-Disk, RAID-0
Supported bus and media type combinations
- SATA HDD
- SAS HDD
- RAID HDD
- RAID SSD (If the media type is unspecified/unknown*)
- SATA SSD + SATA HDD
- SAS SSD + SAS HDD
* RAID controllers without pass-through capability can’t recognize the media type. Such controllers mark both HDD and SSD as Unspecified. In that case, the SSD is used as persistent storage instead of caching devices. Therefore, you can deploy the development kit on those SSDs.
To finally double check if all hardware requirements are met, you can run the pre-req script:
How to Install the Azure Stack Development Kit
Now let’s go on and install the ASDK on your server. You will find the download here:
The download may take some time as it is about +10 GB of size.
After the download has finished, you could extract it to the folder of your choice.
The CloudBuilder.VHDX provides the source for all Azure Stack services and is the basis for the installation. Place this VHDX in a destination folder of your choice and start the ASDK Installer script, that is available here: https://docs.microsoft.com/en-us/azure/azure-stack/asdk/asdk-install.
The installer should look like the above and we then need to choose the button on the left to boot from the cloudbuilder.vhdx as a next step.
On this screen choose the folder where the vhdx file is sitting and point to a specific folder location to install dedicated drivers specific to your hardware. These will be integrated into the vhdx during the preparation phase.
Now we need to configure the administrator account and the password, which will be set identically for all accounts in Azure Stack. Finally, you have the choice of setting a computer name, a time zone, and the static IP configuration.
As Azure Stack ASDK is only supporting one NIC, you will have to choose the appropriate one, all others will be disabled by default.
When setting the Time Server IP, you will need to choose a proper time server as time issues are one of the most occurring errors during the installation. A misconfigured time server is the source for 80% of failed deployments. If you have no other one available, time.windows.com should help.
Now the system is mounting the VHDX file.
Finally, you just need to choose a server reboot option and it will boot into the VHDX. The first step of the deployment is done.
NOTE: If specific hardware drivers, in addition, are needed, install them after this reboot manually.
After the reboot, the original drive C: will be mounted as D:, so you will always have the chance to access these files (for missing drivers or anything else).
After having chosen the left button again, you will have the following deployment options:
- Disconnected (and enabling ADFS only): if you choose this, there is no public Azure connectivity needed, but you will lose multi-tenancy.
- Connected (connected to Azure, Azure China): this is probably the most used option, as it means that you would use Azure AD for Identity Management for Azure Stack itself (not the tenants, just all the administrative stuff)
Now let’s choose the corresponding AAD directly and set the local administrator password.
Let’s configure networking again.
Define the IP Info once again and optionally VLAN ID and DNS Forwarder
After having all steps done, the installation should start properly once you click Deploy.
After logging on with your Azure Credentials, the Script should run for approx. +4-5 hours, depending on the performance of your ASDK host.
When the deployment is finished, it will look like the above image.
If there are any issues that may have stopped the deployment, you can check the logfiles or just run the setup again using the /rerun parameter.
After having finished the second basic step, we will now need to configure Azure Stack to be fully functional.
To check if Azure Stack is working properly, you can check the following URLs:
Admin Portal: https://adminportal.local.azurestack.external
In the administrator portal, you can do things such as:
- Manage the infrastructure (including system health, updates, capacity, etc.)
- Populate the marketplace
- Create subscriptions for users
- Create plans and offers
Tenant Portal: https://portal.local.azurestack.external/
NOTE: You will need to use the account you configured during the deployment setup to login to these portals.
So, the installation took a while, didn’t it? Wonder why? Take a look at the following VMs. This is what you’ve just deployed to your ASDK host. Makes sense now doesn’t it?
From an architecture perspective, it’s important to keep in mind that this is a sandbox installation. Connecting outside services into the ASDK or any of the components inside of it will be virtually impossible. All traffic flows through BGPNAT-VM. Additionally, Azure Stack will not be served with ongoing updates in this type of deployment in order to keep the latest updates you’ll need to reinstall each month.
There are now many other tasks, that we now have to setup/configure (e.g. Registration with Azure, setting up accounts, plans, and offers, installing resource providers), which is something we will look at in the next chapter.
To summarize, Azure Stack ASDK is a great way to start with Azure Stack and will help you figure out if Azure Stack could fit into your existing environment. The next steps would then be going on with a physical multi-node PoC after having talked to your hardware vendor of choice.
What to learn more about the benefits of using Azure stack? Watch our free on-demand webinar Future-proofing your Datacenter with Microsoft Azure Stack
What about you? Have you had a chance to test Azure Stack yet? What were your thoughts? Let us know in the comments section below!
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!