Deze referentiearchitectuur laat zien hoe u virtuele machines (VM's) en een virtueel netwerk implementeert dat is geconfigureerd voor een N-tier-toepassing , met behulp van Apache Cassandra in Linux voor de gegevenslaag.
Architectuur
Een Visio-bestand van deze architectuur downloaden.
Werkstroom
De architectuur heeft de volgende onderdelen:
Algemeen
Resourcegroep. Resourcegroepen worden gebruikt om Azure-resources te groeperen, zodat ze kunnen worden beheerd door levensduur, eigenaar of andere criteria.
Beschikbaarheidszones. Beschikbaarheidszones zijn fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters met onafhankelijke voeding, koeling en netwerken. Door VM's in meerdere zones te plaatsen, wordt de toepassing bestand tegen fouten binnen een zone.
Netwerken en taakverdeling
Virtueel netwerk en subnetten. Elke Virtuele Azure-machine wordt geïmplementeerd in een virtueel netwerk dat kan worden gesegmenteerd in subnetten. Maak een apart subnet voor elke laag.
Toepassingsgateway. Application Gateway is een load balancer van laag 7. In deze architectuur worden HTTP-aanvragen doorgestuurd naar de webfront-end. Application Gateway biedt ook een Web Application Firewall (WAF) die de toepassing beschermt tegen veelvoorkomende aanvallen en beveiligingsproblemen.
Load balancers. Gebruik Azure Standard Load Balancer om netwerkverkeer van de weblaag te distribueren naar de bedrijfslaag.
Netwerkbeveiligingsgroepen. Gebruik NSG's om netwerkverkeer binnen het virtuele netwerk te beperken. In de architectuur met drie lagen die hier wordt weergegeven, accepteert de databaselaag bijvoorbeeld geen verkeer van de webfront-end, alleen vanuit de bedrijfslaag en het beheersubnet.
DDoS-beveiliging. Hoewel het Azure-platform basisbeveiliging biedt tegen DDoS-aanvallen (Distributed Denial of Service), raden we u aan Azure DDoS Network Protection te gebruiken, met verbeterde DDoS-risicobeperkingsfuncties. Bekijk de beveiligingsoverwegingen .
Azure DNS. Azure DNS is een hostingservice voor DNS-domeinen. Het biedt naamomzetting met behulp van de Microsoft Azure-infrastructuur. Door uw domeinen in Azure te hosten, kunt u uw DNS-records met dezelfde referenties, API's, hulpprogramma's en facturering beheren als voor uw andere Azure-services.
Virtuele machines
Apache Cassandra-database. Biedt hoge beschikbaarheid in de gegevenslaag door replicatie en failover in te schakelen.
OpsCenter. Implementeer een bewakingsoplossing zoals DataStax OpsCenter om het Cassandra-cluster te bewaken.
Jumpbox. Ook wel een bastionhost genoemd. Een beveiligde VM in het netwerk die beheerders kunnen gebruiken om verbinding te maken met de andere VM's. De jumpbox heeft een netwerkbeveiligingsgroep die alleen extern verkeer vanaf openbare IP-adressen op een lijst met veilige adressen toelaat. De netwerkbeveiligingsgroep zou RDP-verkeer (extern bureaublad) moeten toestaan.
Aanbevelingen
Uw vereisten kunnen afwijken van de architectuur die hier wordt beschreven. Gebruik deze aanbevelingen als uitgangspunt.
Virtuele machines
Zie Een Virtuele Linux-machine uitvoeren in Azure voor aanbevelingen voor het configureren van de VM's.
Virtueel netwerk
Wanneer u het virtuele netwerk maakt, bepaalt u hoeveel IP-adressen uw resources in elk subnet nodig hebben. Geef een subnetmasker en een netwerkadresbereik op dat groot genoeg is voor de vereiste IP-adressen, met behulp van CIDR-notatie . Gebruik een adresruimte die valt binnen de standaard privé-IP-adresblokken, te weten 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16.
Kies een adresbereik dat niet overlapt met uw on-premises netwerk, voor het geval u later een gateway tussen het VNet en uw on-premises netwerk moet instellen. Nadat u het VNet hebt gemaakt, kunt u het adresbereik niet wijzigen.
Houd rekening met de vereisten voor functionaliteit en beveiliging wanneer u subnetten ontwerpt. Alle VM's binnen dezelfde laag of rol moeten worden geplaatst in hetzelfde subnet dat een beveiligingsgrens kan vormen. Zie Virtuele Azure-netwerken plannen en ontwerpen voor meer informatie over het ontwerpen van VNnet's en subnetten.
Application Gateway
Zie het overzicht van de configuratie van Application Gateway voor meer informatie over het configureren van Application Gateway.
Load balancers
Maak de VM's niet rechtstreeks beschikbaar op internet. Geef in plaats daarvan elke VIRTUELE machine een privé-IP-adres. Clients maken verbinding met behulp van het IP-adres dat is gekoppeld aan de Application Gateway.
Definieer load balancer-regels om netwerkverkeer door te sturen naar de virtuele machines. Maak bijvoorbeeld, om HTTP-verkeer in te schakelen, een regel waarmee poort 80 van de front-endconfiguratie wordt toegewezen aan poort 80 op de back-endadresgroep. Wanneer een client een HTTP-aanvraag naar poort 80 verzendt, selecteert de load balancer een back-end-IP-adres met behulp van een hash-algoritme met het IP-adres van de bron. Clientaanvragen worden verdeeld over alle VM's.
Netwerkbeveiligingsgroepen
Gebruik NSG-regels om het verkeer tussen lagen te beperken. In de hierboven weergegeven architectuur met drie lagen communiceert de weblaag bijvoorbeeld niet rechtstreeks met de databaselaag. Als u dit wilt afdwingen, moet de databaselaag inkomend verkeer van het subnet van de weblaag blokkeren.
- Al het binnenkomende verkeer van het VNet weigeren. (Gebruik de tag
VIRTUAL_NETWORKin de regel.) - Inkomend verkeer vanaf het subnet van de bedrijfslaag toestaan.
- Inkomend verkeer van het subnet van de databaselaag zelf toestaan. Deze regel maakt communicatie mogelijk tussen de database-VM's, die nodig zijn voor databasereplicatie en failover.
- SSH-verkeer (poort 22) toestaan vanuit het jumpbox-subnet. Deze regel zorgt ervoor dat beheerders vanuit de jumpbox verbinding kunnen maken met de databaselaag.
Maak regels 2 – 4 met een hogere prioriteit dan de eerste regel, zodat ze deze overschrijven.
Cassandra
Het is raadzaam DataStax Enterprise voor productie gebruiken, maar deze aanbevelingen zijn van toepassing op elke Cassandra-editie. Zie de handleiding voor het implementeren van DataStax Enterprise in Azure voor meer informatie over het uitvoeren van DataStax in Azure.
Configureer knooppunten in een rack-compatibele modus. Wijs foutdomeinen toe aan racks in het bestand cassandra-rackdc.properties.
U hebt geen load balancer voor het cluster nodig. De client maakt rechtstreeks verbinding met een knooppunt in het cluster.
De implementatiescripts voor deze architectuur gebruiken naamomzetting om het seed-knooppunt te initialiseren voor communicatie tussen clusters (gossip). Als u naamomzetting wilt inschakelen, maakt de implementatie een Azure Privé-DNS-zone met A-records voor de Cassandra-knooppunten. Afhankelijk van uw initialisatiescripts kunt u in plaats daarvan het statische IP-adres gebruiken.
Notitie
Azure Privé-DNS is momenteel beschikbaar als openbare preview.
Jumpbox
Sta ssh-toegang vanaf het openbare internet niet toe op de VM's waarop de toepassingsworkload wordt uitgevoerd. In plaats daarvan moet alle SSH-toegang tot deze VM's via de jumpbox komen. Een beheerder meldt zich aan bij de jumpbox en meldt zich vervolgens aan bij de andere VM's vanuit de jumpbox. De jumpbox staat ssh-verkeer van internet toe, maar alleen van bekende, veilige IP-adressen.
De jumpbox heeft minimale prestatievereisten, dus selecteer een kleine VM-grootte. Maak een openbaar IP-adres voor de jumpbox. Plaats de jumpbox in hetzelfde VNet als de andere VM's, maar in een afzonderlijk beheersubnet.
Als u de jumpbox wilt beveiligen, voegt u een NSG-regel toe waarmee ssh-verbindingen alleen worden toegestaan vanuit een veilige set openbare IP-adressen. Configureer de NSG's voor de andere subnetten om ssh-verkeer van het beheersubnet toe te staan.
Overwegingen
Schaalbaarheid
Schaalsets
Voor de web- en bedrijfslagen kunt u overwegen virtuele-machineschaalsets te gebruiken in plaats van afzonderlijke VM's in een beschikbaarheidsset te implementeren. Met een schaalset kunt u eenvoudig een set identieke VM's implementeren en beheren en de VM's automatisch schalen op basis van metrische prestatiegegevens. Als de belasting op de virtuele machines toeneemt, worden er automatisch extra virtuele machines toegevoegd aan de load balancer.
Er zijn twee basismethoden voor het configureren van virtuele machines die worden geïmplementeerd in een schaalset:
Gebruik extensies om de VIRTUELE machine te configureren nadat deze is geïmplementeerd. Bij deze methode duurt het opstarten van nieuwe VM-exemplaren langer dan bij een VM zonder extensies.
Een beheerde schijf met een aangepaste installatiekopie implementeren. Het implementeren gaat waarschijnlijk sneller bij deze methode. Hiervoor moet u de afbeelding echter up-to-date houden.
Zie Ontwerpoverwegingen voor schaalsets voor meer informatie.
Tip
Wanneer u een oplossing voor automatisch schalen gebruikt, moet u deze ruim van tevoren testen met werkbelastingen op productieniveau.
Abonnementslimieten
Voor elk Azure-abonnement gelden standaardlimieten, inclusief een maximum aantal virtuele machines per regio. U kunt de limiet verhogen door een ondersteuningsaanvraag daartoe in te dienen. Zie Azure-abonnement en servicelimieten, quota en beperkingen voor meer informatie.
Application Gateway
Application Gateway ondersteunt de modus met vaste capaciteit of automatische schaalaanpassing. De modus Vaste capaciteit is handig voor scenario's met consistente en voorspelbare workloads. Overweeg om de modus voor automatisch schalen te gebruiken voor workloads met variabel verkeer. Zie Automatisch schalen en zone-redundante Application Gateway v2 voor meer informatie.
Prestatie-efficiëntie
Zie de aanbevelingen in Apache Cassandra uitvoeren op Azure-VM's voor de beste prestaties van Cassandra op Azure-VM's.
Beschikbaarheid
Beschikbaarheidszones bieden de beste tolerantie binnen één regio. Als u nog hogere beschikbaarheid nodig hebt, kunt u overwegen om de toepassing in twee regio's te repliceren.
Niet alle regio's ondersteunen beschikbaarheidszones en niet alle VM-grootten worden in alle zones ondersteund. Voer de volgende Azure CLI-opdracht uit om de ondersteunde zones te vinden voor elke VM-grootte binnen een regio:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
Als u deze architectuur implementeert in een regio die geen beschikbaarheidszones ondersteunt, plaatst u de VM's voor elke laag in een beschikbaarheidsset. VM's binnen dezelfde beschikbaarheid worden geïmplementeerd op meerdere fysieke servers, rekenrekken, opslageenheden en netwerkswitches voor redundantie. Schaalsets gebruiken automatisch plaatsingsgroepen, die fungeren als een impliciete beschikbaarheidsset.
Wanneer u implementeert in beschikbaarheidszones, gebruikt u de Standard-SKU van Azure Load Balancer en de v2-SKU van Application Gateway. Deze SKU's ondersteunen redundantie tussen zones. Zie voor meer informatie:
- De standaardversie van Load Balancer en beschikbaarheidszones
- Automatisch schalen en zone-redundantie in Application Gateway v2
- Hoe biedt Application Gateway ondersteuning voor hoge beschikbaarheid en schaalbaarheid?
Eén Application Gateway-implementatie kan meerdere exemplaren van de gateway uitvoeren. Voer ten minste twee exemplaren uit voor productieworkloads.
Cassandra-cluster
Voor het Cassandra-cluster zijn de failoverscenario's afhankelijk van de consistentieniveaus die door de toepassing worden gebruikt en het aantal replica's. Zie Gegevensconsistentieen Cassandra configureren voor consistentieniveaus en gebruik in Cassandra: Hoeveel knooppunten worden er gesproken met Quorum? De beschikbaarheid van gegevens in Cassandra wordt bepaald door het consistentieniveau dat wordt gebruikt door de toepassing en het replicatiemechanisme. Zie Data Replication in NoSQL Databases Explained (Uitleg van gegevensreplicatie in NoSQL-databases) voor meer informatie over replicatie in Cassandra.
Statuscontroles
Application Gateway en Load Balancer gebruiken beide statustests om de beschikbaarheid van VM-exemplaren te bewaken.
- Application Gateway maakt altijd gebruik van een HTTP-test.
- Load Balancer kan HTTP of TCP testen. Als een VIRTUELE machine een HTTP-server uitvoert, gebruikt u over het algemeen een HTTP-test. Gebruik anders TCP.
Als een test een exemplaar niet binnen een time-outperiode kan bereiken, stopt de gateway of load balancer met het verzenden van verkeer naar die VM. De test blijft controleren en retourneert de VIRTUELE machine naar de back-endpool als de VIRTUELE machine weer beschikbaar is.
HTTP-tests verzenden een HTTP GET-aanvraag naar een opgegeven pad en luisteren naar een HTTP 200-antwoord. Dit pad kan het hoofdpad (/) zijn of een eindpunt voor statuscontrole waarmee aangepaste logica wordt geïmplementeerd om de status van de toepassing te controleren. Voor het eindpunt moeten anonieme HTTP-aanvragen worden toegestaan.
Zie voor meer informatie over statustests:
Zie het patroon Statuseindpuntbewaking voor overwegingen over het ontwerpen van een statustesteindpunt.
Kostenoptimalisatie
Gebruik de Azure-prijscalculator om de kosten te schatten. Hier volgen enkele andere overwegingen.
Virtuele-machineschaalsets
Virtuele-machineschaalsets zijn beschikbaar op alle Linux-VM-grootten. Alleen de rekeninstanties voor de Azure-VM's die u implementeert worden in rekening gebracht, evenals de andere onderliggende infrastructuurresources die worden verbruikt, zoals opslag en netwerken. Er zijn geen incrementele kosten voor de Virtual Machine Scale Sets-service zelf.
Zie prijzen voor virtuele Linux-machines voor prijsopties voor enkele VM's.
Load balancers
Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels. Binnenkomende NAT-regels zijn gratis. Er geldt geen uurtarief voor de standaardversie van Load Balancer als er geen regels zijn geconfigureerd.
Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.
Beveiliging
Virtuele netwerken zijn een verkeersisolatiegrens in Azure. VM's in één VNet kunnen niet rechtstreeks communiceren met VM's in een ander VNet. Er is wel communicatie mogelijk tussen virtuele machines in hetzelfde VNet, tenzij u netwerkbeveiligingsgroepen (NSG's) maakt om dergelijk verkeer te beperken. Zie voor meer informatie Microsoft-cloudservices en -netwerkbeveiliging.
Definieer de load balancer-regels om te bepalen welk binnenkomend internetverkeer voor de back-end wordt toegestaan. Load balancer-regels bieden echter geen ondersteuning voor lijsten met veilige IP-adressen, dus als u bepaalde openbare IP-adressen aan een veilige lijst wilt toevoegen, moet u een NSG aan het subnet toevoegen.
DMZ. Overweeg een virtueel netwerkapparaat (NVA) toe te voegen om een perimeternetwerk (DMZ) te maken tussen internet en het virtuele Azure-netwerk. NVA is een algemene term voor een virtueel apparaat dat netwerkgerelateerde taken kan uitvoeren, zoals een firewall, pakketinspectie, controle en aangepaste routering. Zie Een DMZ tussen Azure en internet implementeren voor meer informatie.
Versleuteling. Versleutel gevoelige data-at-rest en gebruik Azure Key Vault om de versleutelingssleutels voor de database te beheren. Key Vault kan versleutelingssleutels opslaan in hardwarebeveiligingsmodules (HSM's). Het wordt ook aanbevolen om toepassingsgeheimen, zoals database-verbindingsreeks s, op te slaan in Key Vault.
DDoS-beveiliging. Het Azure-platform biedt standaard DDoS-basisbeveiliging. Deze basisbeveiliging is gericht op het beveiligen van de Azure-infrastructuur als geheel. Hoewel basis-DDoS-beveiliging automatisch wordt ingeschakeld, raden we u aan Azure DDoS-netwerkbeveiliging te gebruiken. Network Protection maakt gebruik van adaptieve afstemming, op basis van de netwerkverkeerspatronen van uw toepassing, om bedreigingen te detecteren. Hierdoor kan het risicobeperking toepassen op DDoS-aanvallen die mogelijk onopgemerkt blijven door het DDoS-beleid voor de hele infrastructuur. Network Protection biedt ook waarschuwingen, telemetrie en analyses via Azure Monitor. Zie Azure DDoS Protection: Best practices en referentiearchitecturen voor meer informatie.
Operationele uitmuntendheid
Omdat alle hoofdresources en hun afhankelijkheden zich in hetzelfde virtuele netwerk in deze architectuur bevinden, worden ze geïsoleerd in dezelfde basisworkload. Dit maakt het eenvoudiger om de specifieke resources van de workload te koppelen aan een DevOps-team, zodat het team alle aspecten van deze resources onafhankelijk kan beheren. Dankzij deze isolatie kunnen DevOps Teams en Services continue integratie en continue levering (CI/CD) uitvoeren.
U kunt ook verschillende implementatiesjablonen gebruiken en integreren met Azure DevOps Services om binnen enkele minuten verschillende omgevingen in te richten, bijvoorbeeld om productie zoals scenario's of belastingtestomgevingen alleen te repliceren wanneer dat nodig is, wat kosten bespaart.
In dit scenario worden uw virtuele machines geconfigureerd met behulp van Extensies voor virtuele machines, omdat ze de mogelijkheid bieden om bepaalde extra software te installeren, zoals Apache Cassandra. Met name met de aangepaste scriptextensie kan willekeurige code op een virtuele machine worden gedownload en uitgevoerd, waardoor het besturingssysteem van een Virtuele Machine onbeperkt kan worden aangepast. VM-extensies worden alleen geïnstalleerd en uitgevoerd tijdens het maken van de VM. Dat betekent dat als het besturingssysteem in een later stadium onjuist wordt geconfigureerd, een handmatige interventie vereist om het terug te zetten naar de juiste status. Hulpprogramma's voor configuratiebeheer kunnen worden gebruikt om dit probleem op te lossen.
Overweeg het gebruik van de Azure Monitor voor het analyseren en optimaliseren van de prestaties van uw infrastructuur, het bewaken en diagnosticeren van netwerkproblemen zonder u aan te melden bij uw virtuele machines. Application Insights is eigenlijk een van de onderdelen van Azure Monitor, waarmee u uitgebreide metrische gegevens en logboeken krijgt om de status van uw volledige Azure-landschap te controleren. Met Azure Monitor kunt u de status van uw infrastructuur volgen.
Zorg ervoor dat u niet alleen uw rekenelementen bewaakt die uw toepassingscode ondersteunen, maar ook uw gegevensplatform, met name uw databases, omdat een lage prestaties van de gegevenslaag van een toepassing ernstige gevolgen kunnen hebben.
Als u de Azure-omgeving wilt testen waarop de toepassingen worden uitgevoerd, moet deze versiebeheerd zijn en worden geïmplementeerd via dezelfde mechanismen als toepassingscode. Vervolgens kan deze ook worden getest en gevalideerd met behulp van DevOps-testparadigma's.
Zie de sectie Operational Excellence in Microsoft Azure Well-Architecture Framework voor meer informatie.