Continuing on the Microsoft Azure Stack (MAS) series, in this topic I am exploring some of the Infrastructure roles. This is off a TP3 Refresh deployment of MAS.
Note Everything is with respect to a point in time. The point in time reference to this is TP3 Refresh timeline, though there may be changes later.
A picture is worth a thousand words. The following is a list of the infrastructure roles available when you deploy TP3 refresh. Click to see expanded/clear view.
The following are a few brief lines of what each one does in addition to several other things they do, that are not exposed.
1. Network Controller – As the name indicates the Network Controller provides network services and is the underlying the controller the Network Resource Provider (RP) talks to, when users submits requests to that RP.
2. Compute Controller – Again as the name indicates the Compute RP needs to talk to this controller before any Compute related resources such as VMs, VMSSs, VMExtensions etc are provisioned.
3. Storage Controller – The controller that Admins/End users need to route their requests to, to provision anything storage related. Also it does all the magic under the covers of Storage Spaces direct, and taking care of disk and data resiliency.
4. Backup Controller – This is an additional service engineered by the MAS team, to do the backup of the infrastructure related data onto a file share in the customers’ data center. Note that for redundancy purposes, one would funnel this backup data to another location also, once the backup controller backs up the infrastructure data & meta-data onto an on-prem file share.
5. Edge Gateway – a single node MAS installation creates an Edge Gateway, through which traffic is routed IN and OUT of the solution.
6. Load Balancer MUX – At a high level, this does the magic of doing the network translation and as well as routing the packets inside the solution. Simply put the SLB MUX load balancer works just like in public Azure to publish the RDP port and any other ports you choose to open up. It provides Load Balancing, NAT’ting, route table propagation (using BGP), along with the enforcing NSG rules – all in one solution – it does the real SDN magic.
7. ADFS – MAS comes with an built in ADFS role. Its primary purpose is if you wanted to operate with direct access to an on-prem AD, then you can use the MAS built-in ADFS to federate with an on-prem AD.
8. Infrastructure Deployment – This is the role that takes care of installing, updating, patching etc.,, of your MAS deployment – aka the ECE component.
9. Health Controller – As the name indicated this does the collection and probing for Health of the system, and as well as surfacing the Health events back to the Health RP and via it to external systems like the portal OR to PS, and APIs who query for health events.
10. ARM – This is the role that sits on top of all of the RPs and provides a consistent management and provisioning layer, allowing life-cycle (CRUD) activities of resources via ARM templates, and mediates and distributes all of the incoming RP requests from the Admins and tenant users alike.
11. Cert Management – MAS uses its own Certificate manager for various things among which it also validates inter-role, inter-RP and other internal communications. It also rotates/expires the certificate aggressively to prevent any tampering with the secured communications that happens inside this sealed system.
12. ACS Ring This provides among various other things, the storage health and life-cycle management of storage related components, and built using the Service Fabric Ring architecture, due to its need to be highly resilient and fault tolerant, to keep the underlying storage sub-systems and data integral and available at all times. Again this does the software defined storage management under the covers, like gobbling up additional disk capacity into the storage cluster transparent to the end users.
PS This information is from deploying the publicly available TP3 refresh bits and from publicly available data/documentation.