Azure-app Service is een krachtig platform voor het hosten van webtoepassingen. Met Azure Functions, gebouwd op basis van de App Service-infrastructuur, kunt u eenvoudig serverloze en gebeurtenisgestuurde rekenworkloads bouwen. Beide services worden vaak gebruikt in oplossingen met meerdere tenants.
Functies van Azure-app Service en Azure Functions die ondersteuning bieden voor multitenancy
Azure-app Service en Azure Functions bevatten veel functies die ondersteuning bieden voor multitenancy.
Aangepaste domeinnamen
Azure-app Service kunt u DNS met jokertekens gebruiken en uw eigen TLS-certificaten met jokertekens toevoegen. Wanneer u tenantspecifieke subdomeinen gebruikt , kunt u dns- en TLS-certificaten met jokertekens eenvoudig schalen naar een groot aantal tenants, zonder dat u handmatig opnieuw hoeft te configureren voor elke nieuwe tenant.
Wanneer u tenantspecifieke aangepaste domeinnamen gebruikt, hebt u mogelijk een groot aantal aangepaste domeinnamen die aan uw app moeten worden toegevoegd. Het kan lastig worden om veel aangepaste domeinnamen te beheren, met name wanneer ze afzonderlijke TLS-certificaten nodig hebben. App Service biedt beheerde TLS-certificaten, waardoor u minder werk nodig hebt wanneer u met aangepaste domeinen werkt. Er zijn echter limieten om rekening mee te houden, zoals het aantal aangepaste domeinen dat kan worden toegepast op één app.
Integratie met Azure Front Door
App Service en Azure Functions kunnen worden geïntegreerd met Azure Front Door om te fungeren als het internetgerichte onderdeel van uw oplossing. Met Azure Front Door kunt u een web application firewall (WAF) en edge-caching toevoegen en andere prestatieoptimalisaties bieden. U kunt uw verkeersstromen eenvoudig opnieuw configureren om verkeer naar verschillende back-ends te leiden, op basis van veranderende zakelijke of technische vereisten.
Wanneer u Azure Front Door gebruikt met een app met meerdere tenants, kunt u deze gebruiken om uw aangepaste domeinnamen te beheren en uw TLS-verbindingen te beëindigen. Uw App Service-toepassing wordt vervolgens geconfigureerd met één hostnaam en al het verkeer stroomt naar die toepassing, zodat u geen aangepaste domeinnamen op meerdere plaatsen kunt beheren.
Zoals in het bovenstaande voorbeeld kan Azure Front Door worden geconfigureerd om de header van Host de aanvraag te wijzigen. De oorspronkelijke Host header die door de client wordt verzonden, wordt doorgegeven via de X-Forwarded-Host header en uw toepassingscode kan deze header gebruiken om de aanvraag toe te wijzen aan de juiste tenant.
Waarschuwing
Als uw toepassing cookies of omleidingsreacties verzendt, moet u er speciaal voor zorgen. Wijzigingen in de headers van de aanvraag Host kunnen deze antwoorden ongeldig maken. Zie de best practice voor het behoud van hostnamen voor meer informatie.
U kunt privé-eindpunten of App Service-toegangsbeperkingengebruiken om ervoor te zorgen dat verkeer door Front Door is gestroomd voordat u uw app bereikt.
Verificatie en autorisatie
Azure-app Service kan verificatietokens valideren namens uw app. Wanneer App Service een aanvraag ontvangt, wordt gecontroleerd of aan elk van de volgende voorwaarden wordt voldaan:
- De aanvraag bevat een token.
- Het token is geldig.
- De aanvraag is geautoriseerd.
Als aan een van de voorwaarden niet wordt voldaan, kan App Service de aanvraag blokkeren of de gebruiker omleiden naar uw id-provider, zodat deze zich kan aanmelden.
Als uw tenants Microsoft Entra ID als hun identiteitssysteem gebruiken, kunt u Azure-app Service configureren om het /common-eindpunt te gebruiken om gebruikerstokens te valideren. Dit zorgt ervoor dat, ongeacht de Microsoft Entra-tenant van de gebruiker, hun tokens worden gevalideerd en geaccepteerd.
U kunt Azure-app Service ook integreren met Azure AD B2C voor verificatie van consumenten.
Meer informatie:
- App Service-autorisatie
- Verificatie configureren in een voorbeeldweb-app met behulp van Azure AD B2C
- Werken met multitenant Microsoft Entra-identiteiten
Toegangsbeperkingen
U kunt het verkeer naar uw app beperken met behulp van toegangsbeperkingen. Deze kunnen worden gebruikt om de IP-adresbereiken of de virtuele netwerken op te geven die verbinding mogen maken met de app.
Wanneer u met een multitenant-oplossing werkt, moet u rekening houden met het maximum aantal toegangsbeperkingsregels. Als u bijvoorbeeld een toegangsbeperkingsregel voor elke tenant moet maken, kunt u het maximum aantal regels overschrijden dat is toegestaan. Als u een groter aantal regels nodig hebt, kunt u overwegen een omgekeerde proxy te implementeren, zoals Azure Front Door.
Isolatiemodellen
Wanneer u met een systeem met meerdere tenants werkt met Azure-app Service of Azure Functions, moet u een beslissing nemen over het isolatieniveau dat u wilt gebruiken. Raadpleeg de tenancymodellen die u moet overwegen voor een multitenant-oplossing en de richtlijnen in de architectuurbenaderingen voor berekening in multitenant-oplossingen om u te helpen het beste isolatiemodel voor uw scenario te selecteren.
Wanneer u met Azure-app Service en Azure Functions werkt, moet u rekening houden met de volgende belangrijke concepten:
- In Azure-app Service vertegenwoordigt een plan uw hostinginfrastructuur. Een app vertegenwoordigt één toepassing die wordt uitgevoerd op die infrastructuur. U kunt meerdere apps implementeren in één abonnement.
- In Azure Functions worden uw hosting en toepassing ook gescheiden, maar er zijn extra hostingopties beschikbaar voor elastische hosting, waarbij Azure Functions schaalaanpassing voor u beheert. Ter vereenvoudiging verwijzen we naar de hostinginfrastructuur als een plan in dit artikel, omdat de hier beschreven principes van toepassing zijn op zowel App Service als Azure Functions, ongeacht het hostingmodel dat u gebruikt.
De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenancy-isolatiemodellen voor Azure-app Service en Azure Functions:
| Overweging | Gedeelde apps | Apps per tenant met gedeelde abonnementen | Abonnementen per tenant |
|---|---|---|---|
| Configuratie-isolatie | Laag | Gemiddeld. Instellingen op app-niveau zijn toegewezen aan de tenant, instellingen op planniveau worden gedeeld | Hoog. Elke tenant kan een eigen configuratie hebben |
| Isolatie van prestaties | Laag | Laag/middelgroot. Mogelijk onderhevig aan problemen met lawaaierige buren | Hoog |
| Implementatiecomplexiteit | Laag | Medium | Hoog |
| Operationele complexiteit | Laag | Hoog | Hoog |
| Resourcekosten | Laag | Laag/hoog, afhankelijk van de toepassing | Hoog |
| Voorbeeldscenario | Grote multitenant-oplossing met een gedeelde toepassingslaag | Toepassingen migreren die niet op de hoogte zijn van tenancy naar Azure en tegelijkertijd kostenefficiëntie krijgen | Toepassingslaag met één tenant |
Gedeelde apps
U kunt een gedeelde toepassing implementeren op één abonnement en de gedeelde toepassing gebruiken voor al uw tenants.
Dit is meestal de meest kostenefficiënte optie en vereist de minst operationele overhead omdat er minder resources zijn om te beheren. U kunt het totale plan schalen op basis van belasting of vraag, en alle tenants die het plan delen, profiteren van de verhoogde capaciteit.
Het is belangrijk om rekening te houden met de Quota en limieten van App Service, zoals het maximum aantal aangepaste domeinen dat kan worden toegevoegd aan één app en het maximum aantal exemplaren van een plan dat kan worden ingericht.
Als u dit model wilt kunnen gebruiken, moet uw toepassingscode multitenancybewust zijn.
Apps per tenant met gedeelde abonnementen
U kunt er ook voor kiezen om uw plan te delen tussen meerdere tenants, maar afzonderlijke apps voor elke tenant te implementeren. Dit biedt u logische isolatie tussen elke tenant en deze benadering biedt u de volgende voordelen:
- Kostenefficiëntie: Door uw hostinginfrastructuur te delen, kunt u in het algemeen uw totale kosten per tenant verlagen.
- Scheiding van configuratie: de app van elke tenant kan een eigen domeinnaam, TLS-certificaat, toegangsbeperkingen en tokenautorisatiebeleid toepassen.
- Scheiding van upgrades: de binaire bestanden van elke tenant kunnen onafhankelijk van andere apps in hetzelfde abonnement worden bijgewerkt.
Omdat de rekenresources van het plan echter worden gedeeld, kunnen de apps onderhevig zijn aan het probleem met Noisy Neighbor. Daarnaast gelden er limieten voor het aantal apps dat in één abonnement kan worden geïmplementeerd.
Notitie
Gebruik geen implementatiesites voor verschillende tenants. Sites bieden geen resource-isolatie. Ze zijn ontworpen voor implementatiescenario's wanneer u gedurende korte tijd meerdere versies van uw app moet uitvoeren, zoals blauwgroene implementaties en een strategie voor de kanarie-implementatie.
Abonnementen per tenant
Het sterkste isolatieniveau is het implementeren van een toegewezen plan voor een tenant. Dit toegewezen plan zorgt ervoor dat de tenant volledig gebruik heeft van alle serverbronnen die aan dat plan zijn toegewezen.
Met deze aanpak kunt u uw oplossing schalen om prestatie-isolatie te bieden voor elke tenant en om het probleem met Noisy Neighbor te voorkomen. Het heeft echter ook een hogere kosten omdat de resources niet worden gedeeld met meerdere tenants. U moet ook rekening houden met het maximum aantal abonnementen dat kan worden geïmplementeerd in één Azure-resourcegroep.
Host-API's
U kunt API's hosten op zowel Azure-app Service als Azure Functions. Uw keuze voor het platform is afhankelijk van de specifieke functieset en schaalopties die u nodig hebt.
Welk platform u ook gebruikt om uw API te hosten, overweeg om Azure API Management vóór uw API-toepassing te gebruiken. API Management biedt veel functies die nuttig kunnen zijn voor multitenant-oplossingen, waaronder de volgende:
- Een gecentraliseerd punt voor alle verificatie. Dit kan omvatten het bepalen van de tenant-id van een tokenclaim of andere metagegevens van aanvragen.
- Aanvragen omleiden naar verschillende API-back-ends, die mogelijk zijn gebaseerd op de tenant-id van de aanvraag. Dit kan handig zijn wanneer u meerdere implementatiestempels host, met hun eigen onafhankelijke API-toepassingen, maar u moet één API-URL voor alle aanvragen hebben.
Netwerken en multitenancy
IP-adressen
Veel multitenant-toepassingen moeten verbinding maken met on-premises netwerken van tenants om gegevens te verzenden.
Als u uitgaand verkeer van een bekend statisch IP-adres of van een set bekende statische IP-adressen wilt verzenden, kunt u overwegen een NAT-gateway te gebruiken. Zie Overwegingen voor Azure NAT Gateway voor multitenancy voor meer informatie over het gebruik van NAT Gateway in multitenant-oplossingen. App Service biedt richtlijnen voor het integreren met een NAT-gateway.
Als u geen statisch uitgaand IP-adres nodig hebt, maar in plaats daarvan moet u af en toe het IP-adres controleren dat uw toepassing gebruikt voor uitgaand verkeer, kunt u een query uitvoeren op de huidige IP-adressen van de App Service-implementatie.
Targets
Omdat App Service zelf een multitenant-service is, moet u rekening houden met hoe u gedeelde resources gebruikt. Netwerken is een gebied waarop u speciale aandacht moet besteden, omdat er limieten zijn die van invloed zijn op hoe uw toepassing kan werken met zowel binnenkomende als uitgaande netwerkverbindingen, waaronder SNAT-poortlimieten (Source Network Address Translation) en TCP-poortlimieten.
Als uw toepassing verbinding maakt met een groot aantal databases of externe services, loopt uw app mogelijk het risico dat de SNAT-poort wordt uitgeput. Over het algemeen geeft SNAT-poortuitputting aan dat uw code tcp-verbindingen niet correct hergebruikt. Zelfs in een multitenant-oplossing moet u ervoor zorgen dat u de aanbevolen procedures voor het hergebruik van verbindingen volgt.
In sommige multitenant-oplossingen kan het aantal uitgaande verbindingen met verschillende IP-adressen echter leiden tot uitputting van de SNAT-poort, zelfs wanneer u goede coderingsprocedures volgt. In deze scenario's kunt u een van de volgende opties overwegen:
- Implementeer NAT Gateway om het aantal SNAT-poorten te verhogen dat beschikbaar is voor uw toepassing. Zie Overwegingen voor Azure NAT Gateway voor multitenancy voor meer informatie over het gebruik van NAT Gateway in multitenant-oplossingen.
- Gebruik service-eindpunten wanneer u verbinding maakt met Azure-services om load balancer-limieten te omzeilen.
Zelfs met deze besturingselementen kunt u limieten benaderen met een groot aantal tenants, dus u moet van plan zijn om te schalen naar aanvullende App Service-plannen of implementatiestempels.
Inzenders
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- John Downs | Principal Customer Engineer, FastTrack voor Azure
Andere Inzenders:
- Thiago Almeida | Principal Program Manager, Azure Functions
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
Bekijk resources voor architecten en ontwikkelaars van multitenant-oplossingen.