Continuing on the 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.
Infrastructure Roles
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.
Infrastructure Roles
The following is a one liner of what each one does in addition to several other things they do, that are not exposed.
1. Network Controller – As the name indicates provides network services and is the underlying the controller the Network 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 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, I would funnel this to another location also, once the backup controller backs up the 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 and NAT’ting, along with the NSG all in one solution – it is 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 this 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 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 is the role made up of components 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.
PS This information is from deploying the publicly available TP3 refresh bits and from publicly available data/documentation.
