N-tier-toepassing met Apache Cassandra

DNS
Load Balancer
Monitor
Virtual Machines
Virtual Network

Deze referentiearchitectuur laat zien hoe u virtuele machines (VM's) implementeert en een virtueel netwerk dat is geconfigureerd voor een toepassing met n-aantal lagen, met behulp van Apache Cassandra in Linux voor de gegevenslaag. Deze oplossing implementeren.

Architectuur met meerdere lagen met Microsoft Azure

Een Visio-bestand van deze architectuur downloaden.

Architectuur

De architectuur heeft de volgende onderdelen:

Algemeen

  • Resourcegroep. Resourcegroepen worden gebruikt om Azure-resources te groepen, zodat ze kunnen worden beheerd op basis van 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 Azure-VM 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 laag 7 load balancer. In deze architectuur worden HTTP-aanvragen gerouteerd 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 naar de bedrijfslaag te distribueren.

  • Netwerkbeveiligingsgroepen (NSG's). 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 van de bedrijfslaag en het beheersubnet.

  • DDoS Protection. Hoewel het Azure-platform basisbeveiliging biedt tegen DDoS-aanvallen (Distributed Denial of Service), raden we u aan DDoS Protection Standardte gebruiken, dat verbeterde DDoS-beperkingsfuncties heeft. Zie Beveiligingsoverwegingen.

  • Azure DNS. Azure DNS is een hostingservice voor DNS-domeinen. Het biedt naamoplossing met behulp 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. Wordt 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 linux-VM uitvoeren op 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 configuratieoverzicht voor Application Gateway over het configureren Application Gateway configuratie.

Load balancers

Maak de VM's niet rechtstreeks bloot aan internet. Geef in plaats daarvan elke VM een privé-IP-adres. Clients maken verbinding met behulp van het IP-adres dat is gekoppeld aan 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 architectuur met drie lagen die hierboven wordt weergegeven, 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.

  1. Al het binnenkomende verkeer van het VNet weigeren. (Gebruik de tag VIRTUAL_NETWORK in de regel.)
  2. Sta inkomende verkeer van het subnet van de bedrijfslaag toe.
  3. Sta het inkomende verkeer van het subnet van de databaselaag zelf toe. Deze regel staat communicatie toe tussen de database-VM's, die nodig zijn voor databasereplicatie en failover.
  4. SSH-verkeer (poort 22) vanaf het jumpbox-subnet toestaan. 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 maken gebruik van naamresolutie om het seed-knooppunt te initialiseren voor communicatie binnen het cluster (24). Voor het inschakelen van naamresolutie 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 geen SSH-toegang van het openbare internet toe tot de VM's die de workload van de toepassing uitvoeren. 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 vanaf 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 die alleen ssh-verbindingen vanaf een veilige set openbare IP-adressen toestaat. Configureer de NSG's voor de andere subnetten om SSH-verkeer van het beheersubnet toe te staan.

Schaalbaarheidsoverwegingen

Schaalsets

Voor de web- en bedrijfslagen kunt u virtuele-machineschaalsetsgebruiken 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 VM 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. U moet 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 voor vaste capaciteit of de modus voor automatisch schalen. De modus Vaste capaciteit is handig voor scenario's met consistente en voorspelbare workloads. Overweeg het gebruik van de modus voor automatisch schalen voor werkbelastingen met variabele verkeer. Zie Automatisch schalen en zone-redundante Application Gateway v2 voor meer informatie.

Prestatieoverwegingen

Zie de aanbevelingen in Apache Cassandra uitvoeren op Azure-VM's voor de beste prestaties van Cassandra op virtuele Azure-VM's.

Beschikbaarheidsoverwegingen

Beschikbaarheidszones bieden de beste tolerantie binnen één regio. Als u nog hogere beschikbaarheid nodig hebt, kunt u overwegen om de toepassing te repliceren naar twee regio's.

Niet alle regio's ondersteunen beschikbaarheidszones en niet alle VM-grootten worden ondersteund in alle zones. Voer de volgende Azure CLI-opdracht uit om de ondersteunde zones voor elke VM-grootte binnen een regio te vinden:

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 ondersteuning biedt voor beschikbaarheidszones, moet u de VM's voor elke laag in een beschikbaarheidsset zetten. VM's binnen dezelfde beschikbaarheid worden geïmplementeerd op meerdere fysieke servers, rekenrekken, opslageenheden en netwerkswitches voor redundantie. Schaalsets gebruiken automatisch plaatsingsgroependie fungeren als een impliciete beschikbaarheidsset.

Wanneer u implementeert in beschikbaarheidszones, gebruikt u de Standaard-SKU van Azure Load Balancer en de v2-SKU van Application Gateway. Deze SKU's ondersteunen redundantie in meerdere zones. Zie voor meer informatie:

Met één Application Gateway-implementatie kunnen meerdere exemplaren van de gateway worden uitgevoerd. Voor productieworkloads moet u ten minste twee exemplaren uitvoeren.

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 Gegevensconsistentie configureren en Cassandra: met hoeveel knooppunten wordt gesproken met Quorum voor consistentieniveaus en gebruik in Cassandra. 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 beide statustests gebruiken om de beschikbaarheid van VM-exemplaren te bewaken.

  • Application Gateway maakt altijd gebruik van een HTTP-test.
  • Load Balancer kunt HTTP of TCP testen. Over het algemeen, als op een VM een HTTP-server wordt uitgevoerd, gebruikt u een HTTP-test. Gebruik anders TCP.

Als een test een exemplaar niet binnen een time-outperiode kan bereiken, stopt de gateway of load balancer het verzenden van verkeer naar die VM. De test blijft het controleren en retournt de VM naar de back-endpool als de VM weer beschikbaar wordt.

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 dat aangepaste logica implementeert om de status van de toepassing te controleren. Voor het eindpunt moeten anonieme HTTP-aanvragen worden toegestaan.

Zie voor meer informatie over statustests:

Zie Health Endpoint Monitoring pattern (Patroon Status van eindpuntbewaking) voor overwegingen over het ontwerpen van een eindpunt voor een statustest.

Kostenoverwegingen

Gebruik de Azure-prijscalculator om een schatting te maken van de kosten. Hier zijn enkele andere overwegingen.

Virtuele-machineschaalsets

Virtuele-machineschaalsets zijn beschikbaar in alle Linux-VM-grootten. Er worden alleen kosten in rekening gebracht voor de Azure-VM's die u implementeert, evenals eventuele aanvullende onderliggende infrastructuurbronnen die worden gebruikt, zoals opslag en netwerken. Er worden geen incrementele kosten in rekening gebracht voor de service voor virtuele-machineschaalsets zelf.

Zie Prijzen voor virtuele Linux-VM's voor prijsopties voor enkele VM's.

Load balancers

Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels. Inkomende NAT-regels zijn gratis. Er worden geen kosten per uur in rekening Standard Load Balancer er geen regels zijn geconfigureerd.

Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.

Beveiligingsoverwegingen

Virtuele netwerken zijn een verkeersisolatiegrens in Azure. VM's in het ene 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 databaseverbindingsreeksen, 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 DDoS-basisbeveiliging automatisch wordt ingeschakeld, raden we u aan om DDoS Protection Standard te gebruiken. Standaardbeveiliging maakt gebruik van adaptieve afstemming, op basis van de netwerkverkeerspatronen van uw toepassing, om bedreigingen te detecteren. Hierdoor kunnen oplossingen worden toegepast tegen DDoS-aanvallen die mogelijk niet worden opgemerkt door het DDoS-beleid voor de hele infrastructuur. Standaardbeveiliging biedt ook waarschuwingen, telemetrie en analyses via Azure Monitor. Zie voor meer informatie Azure DDoS Protection: Best practices en referentiearchitecten.

De oplossing implementeren

Een implementatie voor deze referentiearchitectuur is beschikbaar op GitHub.

Als u een regio opgeeft die beschikbaarheidszones ondersteunt, worden de VM's geïmplementeerd in beschikbaarheidszones. Anders worden de VM's geïmplementeerd in beschikbaarheidssets. Zie Servicesondersteuning per regio voor een lijst met regio's die beschikbaarheidszones ondersteunen.

Vereisten

  1. Kloon, vertak of download het zip-bestand voor de GitHub-opslagplaats met referentiearchitecturen.

  2. Installeer Azure CLI 2.0.

  3. Node en NPM installeren

  4. Installeer het NPM-pakket met Azure-bouwstenen.

    npm install -g @mspnp/azure-building-blocks
    
  5. Meld u via een opdrachtprompt, Bash-prompt of PowerShell-prompt als volgt aan bij uw Azure-account:

    az login
    

De oplossing implementeren met azbb

Volg deze stappen om de Linux-VM's voor een referentiearchitectuur voor een toepassing met meerdere lagen te implementeren:

  1. Navigeer virtual-machines\n-tier-linux naar de map voor de opslagplaats die u in stap 1 van de bovenstaande vereisten hebt gekloond.

  2. Het parameterbestand bevat een standaardgebruikersnaam en -wachtwoord voor beheerders voor elke VM in de implementatie. Wijzig deze voordat u de referentiearchitectuur implementeert. Open het bestand n-tier-linux.json en vervang elk veld n-tier-linux.json en adminPassword door uw nieuwe instellingen. Sla het bestand op.

  3. Implementeer de referentiearchitectuur met behulp van het hulpprogramma azbb, zoals hieronder wordt weergegeven.

    azbb -s <your subscription_id> -g <your resource_group_name> -l <azure region> -p n-tier-linux.json --deploy
    

DevOps overwegingen

In deze architectuur gebruikt u een Azure-bouwstenensjabloon voor het inrichten van de Azure-resources en de afhankelijkheden ervan. Omdat alle hoofdresources en hun afhankelijkheden zich in hetzelfde virtuele netwerk hebben, zijn ze geïsoleerd in dezelfde basisworkload, waardoor het eenvoudiger is om de specifieke resources van de workload te koppelen aan een DevOps-team, zodat het team alle aspecten van deze resources onafhankelijk kan beheren. Deze isolatie stelt DevOps Teams en Services in staat om continue integratie en continue levering (CI/CD) uit te voeren.

U kunt ook verschillende implementatiesjablonen gebruiken en deze integreren met Azure DevOps Services om binnen enkele minuten verschillende omgevingen in terichten, bijvoorbeeld om productiescenario's te repliceren, zoals scenario's of omgevingen voor belastingstests, wat kosten bespaart.

In dit sceanario worden uw virtuele machines geconfigureerd met behulp van extensies van virtuele machines, omdat ze de mogelijkheid bieden om bepaalde aanvullende software te installeren, zoals Apache Cassandra. Met de aangepaste scriptextensie kunnen met name willekeurige code op een virtuele machine worden gedownload en uitgevoerd, waardoor het besturingssysteem van een virtuele Azure-machine onbeperkt kan worden aangepast. VM-extensies worden alleen geïnstalleerd en uitgevoerd tijdens het maken van de VM. Dit betekent dat als het besturingssysteem in een latere fase onjuist wordt geconfigureerd, er handmatig moet worden ingegrepen 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 in feite een van de onderdelen van Azure Monitor, die u uitgebreide metrische gegevens en logboeken biedt om de status van uw volledige Azure-landschap te controleren. Azure Monitor helpt u de status van uw infrastructuur te 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 waarin de toepassingen worden uitgevoerd, moet de versie worden beheerd en 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.

Volgende stappen