N-nivåprogram med Apache Cassandra

Azure DNS
Azure Load Balancer
Azure Monitor
Azure Virtual Machines
Azure Virtual Network

Den här referensarkitekturen visar hur du distribuerar virtuella datorer och ett virtuellt nätverk som konfigurerats för ett N-nivåprogram med Apache Cassandra på Linux för datanivån.

Arkitektur

Diagram that shows the N-tier architecture using Microsoft Azure.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Arkitekturen har följande komponenter:

Allmänt

  • Resursgrupp. Resursgrupper används för att gruppera Azure-resurser så att de kan hanteras efter livslängd, ägare eller andra kriterier.

  • Tillgänglighetszoner. Tillgänglighetszoner är fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter med oberoende ström, kylning och nätverk. Genom att placera virtuella datorer mellan zoner blir programmet motståndskraftigt mot fel i en zon.

Nätverks- och belastningsutjämning

  • Virtuellt nätverk och undernät. Varje virtuell Azure-dator distribueras till ett virtuellt nätverk som kan segmenteras i undernät. Skapa ett separat undernät för varje nivå.

  • Programgateway. Application Gateway är en layer 7-lastbalanserare. I den här arkitekturen dirigerar den HTTP-begäranden till webbklientdelen. Application Gateway tillhandahåller också en brandvägg för webbprogram (WAF) som skyddar programmet mot vanliga sårbarheter och sårbarheter.

  • Lastbalanserare. Använd Azure Standard Load Balancer för att distribuera nätverkstrafik från webbnivån till affärsnivån.

  • Nätverkssäkerhetsgrupper (NSG:er). Använd NSG:er för att begränsa nätverkstrafiken i det virtuella nätverket. I den arkitektur med tre nivåer som visas här accepterar databasnivån till exempel inte trafik från webbklientdelen, endast från affärsnivån och hanteringsundernätet.

  • DDoS-skydd. Även om Azure-plattformen ger grundläggande skydd mot DDoS-attacker (Distribuerad överbelastning) rekommenderar vi att du använder Azure DDoS Network Protection, som har förbättrade DDoS-åtgärdsfunktioner. Se Säkerhetsöverväganden.

  • Azure DNS. Azure DNS är en värdtjänst för DNS-domäner. Den tillhandahåller namnmatchning med hjälp av Microsoft Azure-infrastrukturen. Genom att använda Azure som värd för dina domäner kan du hantera dina DNS-poster med samma autentiseringsuppgifter, API:er, verktyg och fakturering som för dina andra Azure-tjänster.

Virtuella datorer

  • Apache Cassandra-databas. Ger hög tillgänglighet på datanivån, genom att aktivera replikering och redundans.

  • OpsCenter. Distribuera en övervakningslösning som DataStax OpsCenter för att övervaka Cassandra-klustret.

  • Jumpbox. Kallas även för en skyddsmiljö-värd. En säker virtuell dator i nätverket som administratörer använder för att ansluta till andra virtuella datorer. Jumpboxen har en NSG som endast tillåter fjärrtrafik från offentliga IP-adresser på en säker lista. NSG: ska tillåta trafik för fjärrskrivbord (RDP).

Rekommendationer

Dina krav kan vara annorlunda från den arkitektur som beskrivs här. Använd de här rekommendationerna som utgångspunkt.

Virtuella datorer

Rekommendationer om hur du konfigurerar de virtuella datorerna finns i Köra en virtuell Linux-dator på Azure.

Virtuellt nätverk

När du skapar det virtuella nätverket avgör du hur många IP-adresser dina resurser i varje undernät kräver. Ange en nätmask och ett nätverksadressintervall som är tillräckligt stort för de nödvändiga IP-adresserna med hjälp av CIDR-notation . Använd ett adressutrymme som ligger inom standarden för privata IP-adressblock, som är 10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16.

Välj ett adressintervall som inte överlappar det lokala nätverket, om du behöver konfigurera en gateway mellan det virtuella nätverket och ditt lokala nätverk senare. När du skapat det virtuella nätverket kan du inte ändra adressintervallet.

Utforma undernät och ha både funktionalitet och säkerhetskrav i åtanke. Alla virtuella datorer inom samma nivå eller roll bör ingå i samma undernät, vilket kan vara en säkerhetsgräns. Läs mer om hur du utformar virtuella nätverk och undernät i informationen om hur du planerar och utformar virtuella Azure-nätverk.

Application Gateway

Information om hur du konfigurerar Application Gateway finns i Konfigurationsöversikt för Application Gateway.

lastbalanserare

Exponera inte de virtuella datorerna direkt till Internet. Ge i stället varje virtuell dator en privat IP-adress. Klienter ansluter med den IP-adress som är associerad med Application Gateway.

Definiera regler för lastbalanseraren för att dirigera nätverkstrafik till de virtuella datorerna. Om du exempelvis vill aktivera HTTP-trafik, skapar du en regel som mappar port 80 från klientdelskonfigurationen till port 80 på serverdelsadresspoolen. När en klient skickar en HTTP-begäran till port 80 väljer lastbalanseraren en serverdels-IP-adress med hjälp av en hash-algoritm som innehåller källans IP-adress. Klientbegäranden distribueras över alla virtuella datorer.

Nätverkssäkerhetsgrupper

Använd NSG-regler för att begränsa trafiken mellan nivåer. I den arkitektur med tre nivåer som visas ovan kommunicerar webbnivån till exempel inte direkt med databasnivån. Om du vill göra detta bör databasnivån blockera inkommande trafik från undernät på webbnivå.

  1. Neka all inkommande trafik från det virtuella nätverket. (Använd taggen VIRTUAL_NETWORK i regeln.)
  2. Tillåt inkommande trafik från undernätet på affärsnivå.
  3. Tillåt inkommande trafik från själva undernätet på databasnivån. Den här regeln tillåter kommunikation mellan de virtuella databasdatorerna, vilket krävs för databasreplikering och redundans.
  4. Tillåt ssh-trafik (port 22) från jumpbox-undernätet. Den här regeln låter administratörer ansluta till databasnivån från jumpbox.

Skapa regler 2– 4 med högre prioritet än den första regeln, så att de åsidosätter den.

Cassandra

Vi rekommenderar DataStax Enterprise för produktionsanvändning, men de här rekommendationerna gäller för alla Cassandra-versioner. Mer information om hur du kör DataStax i Azure finns i distributionsguiden för DataStax Enterprise i Azure.

Konfigurera noder i rackmedvetet läge. Mappa feldomäner till rack i filen cassandra-rackdc.properties.

Du behöver inte ha en lastbalanserare framför klustret. Klienten ansluter direkt till en nod i klustret.

Distributionsskripten för den här arkitekturen använder namnmatchning för att initiera startnoden för kommunikation mellan kluster (skvaller). För att aktivera namnmatchning skapar distributionen en Azure Privat DNS-zon med A-poster för Cassandra-noderna. Beroende på initieringsskripten kanske du kan använda den statiska IP-adressen i stället.

Kommentar

Azure Privat DNS finns för närvarande i offentlig förhandsversion.

Jumpbox

Tillåt inte ssh-åtkomst från det offentliga Internet till de virtuella datorer som kör programarbetsbelastningen. I stället måste all ssh-åtkomst till dessa virtuella datorer komma via jumpboxen. En administratör loggar in på jumpbox som sedan loggar in på den andra virtuella datorn från jumpbox. Jumpboxen tillåter ssh-trafik från Internet, men endast från kända, säkra IP-adresser.

Jumpboxen har minimala prestandakrav, så välj en liten VM-storlek. Skapa en offentlig IP-adress för jumpbox. Placera jumpbox i samma virtuella nätverk som de andra virtuella datorerna, men i ett separat hanteringsundernät.

För att skydda jumpboxen lägger du till en NSG-regel som endast tillåter ssh-anslutningar från en säker uppsättning offentliga IP-adresser. Konfigurera NSG:erna för de andra undernäten så att ssh-trafik tillåts från hanteringsundernätet.

Att tänka på

Skalbarhet

Skalningsuppsättningar

För webb- och affärsnivåer bör du överväga att använda vm-skalningsuppsättningar i stället för att distribuera separata virtuella datorer till en tillgänglighetsuppsättning. En skalningsuppsättning gör det enkelt att distribuera och hantera en uppsättning identiska virtuella datorer och autoskalning av de virtuella datorerna baserat på prestandamått. När belastningen på de virtuella datorerna ökar läggs ytterligare virtuella datorer automatiskt till i lastbalanseraren.

Det finns två grundläggande sätt att konfigurera virtuella datorer som har distribueras i en skalningsuppsättning:

  • Använd tillägg för att konfigurera den virtuella datorn när den har distribuerats. Nya VM-instanser kan ta längre tid att starta än en virtuell dator utan tillägg med den här metoden.

  • Distribuera en hanterad disk med en anpassad diskavbildning. Det här alternativet kan gå snabbare att distribuera. Det kräver dock att du håller avbildningen uppdaterad.

Mer information finns i Designöverväganden för skalningsuppsättningar.

Dricks

När du använder en autoskalningslösning bör du testa den med arbetsbelastningar på produktionsnivå i förväg.

Prenumerationsgränser

Varje Azure-prenumeration har standardgränser, inklusive ett maximalt antal virtuella datorer per region. Du kan höja gränsen genom att arkivera en supportbegäran. Läs mer i Azure-prenumeration och tjänstbegränsningar, kvoter och begränsningar.

Application Gateway

Application Gateway stöder läge för fast kapacitet eller autoskalningsläge. Läget för fast kapacitet är användbart för scenarier med konsekventa och förutsägbara arbetsbelastningar. Överväg att använda autoskalningsläge för arbetsbelastningar med variabel trafik. Mer information finns i Autoskalning och Zonredundant Application Gateway v2.

Prestandaeffektivitet

Information om hur du får bästa prestanda från Cassandra på virtuella Azure-datorer finns i rekommendationerna i Kör Apache Cassandra på virtuella Azure-datorer.

Tillgänglighet

Tillgänglighetszoner ger bästa återhämtning inom en enda region. Om du behöver ännu högre tillgänglighet kan du överväga att replikera programmet i två regioner.

Alla regioner stöder inte tillgänglighetszoner och inte alla VM-storlekar stöds i alla zoner. Kör följande Azure CLI-kommando för att hitta de zoner som stöds för varje VM-storlek i en region:

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

Om du distribuerar den här arkitekturen till en region som inte stöder tillgänglighetszoner placerar du de virtuella datorerna för varje nivå i en tillgänglighetsuppsättning. Virtuella datorer med samma tillgänglighet distribueras över flera fysiska servrar, beräkningsrack, lagringsenheter och nätverksväxlar för redundans. Skalningsuppsättningar använder automatiskt placeringsgrupper, som fungerar som en implicit tillgänglighetsuppsättning.

När du distribuerar till tillgänglighetszoner använder du Standard SKU för Azure Load Balancer och v2 SKU för Application Gateway. Dessa SKU:er stöder redundans mellan zoner. Mer information finns i:

En enda Application Gateway-distribution kan köra flera instanser av gatewayen. Kör minst två instanser för produktionsarbetsbelastningar.

Cassandra-kluster

För Cassandra-klustret beror redundansscenarierna på de konsekvensnivåer som används av programmet och antalet repliker. Information om konsekvensnivåer och användning i Cassandra finns i Konfigurera datakonsekvens och Cassandra: Hur många noder pratas med kvorum? Datatillgänglighet i Cassandra bestäms av den konsekvensnivå som används av programmet och replikeringsmekanismen. Information om replikering i Cassandra finns i Data Replication in NoSQL Databases Explained (Förklaring av datareplikering i NoSQL-databaser).

Hälsotillståndsavsökningar

Både Application Gateway och Load Balancer använder hälsoavsökningar för att övervaka tillgängligheten för virtuella datorinstanser.

  • Application Gateway använder alltid en HTTP-avsökning.
  • Load Balancer kan testa antingen HTTP eller TCP. Om en virtuell dator kör en HTTP-server använder du vanligtvis en HTTP-avsökning. Annars använder du TCP.

Om en avsökning inte kan nå en instans inom en tidsgräns slutar gatewayen eller lastbalanseraren att skicka trafik till den virtuella datorn. Avsökningen fortsätter att kontrollera och returnerar den virtuella datorn till serverdelspoolen om den virtuella datorn blir tillgänglig igen.

HTTP-avsökningar skickar en HTTP GET-begäran till en angiven sökväg och lyssnar efter ett HTTP 200-svar. Den här sökvägen kan vara rotsökvägen ("/" eller en slutpunkt för hälsoövervakning som implementerar viss anpassad logik för att kontrollera programmets hälsotillstånd. Slutpunkten måste tillåta anonyma HTTP-begäranden.

Mer information om hälsoavsökningar finns i:

Mer information om hur du utformar en slutpunkt för hälsoavsökning finns i Hälsoslutpunktsövervakningsmönster.

Kostnadsoptimering

Använd Priskalkylatorn för Azure för att beräkna kostnaderna. Här följer några andra överväganden.

Skalningsuppsättningar för virtuella datorer

Vm-skalningsuppsättningar är tillgängliga för alla storlekar på virtuella Linux-datorer. Du debiteras endast för de virtuella Azure-datorer du väljer, samt övriga underliggande infrastrukturresurser som förbrukas, till exempel lagring och nätverk. Inga ytterligare avgifter debiteras för själva Virtual Machine Scale Sets-tjänsten.

Prisalternativ för enskilda virtuella datorer finns i Prissättning för virtuella Linux-datorer.

lastbalanserare

Du debiteras endast för antalet konfigurerade regler för belastningsutjämning och utgående trafik. Inkommande NAT-regler är kostnadsfria. Ingen timavgift debiteras för Standard Load Balancer om inga regler har konfigurerats.

Mer information finns i kostnadsavsnittet i Microsoft Azures välstrukturerade ramverk.

Säkerhet

Virtuella nätverk utgör en gräns för isolering av trafik i Azure. Virtuella datorer i ett virtuellt nätverk kan inte kommunicera direkt med virtuella datorer i ett annat virtuellt nätverk. Virtuella datorer i samma virtuella nätverk kan kommunicera, om du inte skapar nätverkssäkerhetsgrupper (NSG:er) för att begränsa trafiken. Mer information finns i Microsofts molntjänster och nätverkssäkerhet.

För inkommande Internet-trafik definierar reglerna för lastbalanseraren vilken trafik som kan nå serverdelen. Lastbalanserarens regler stöder dock inte säkra IP-listor, så om du vill lägga till vissa offentliga IP-adresser i den säkra listan lägger du till en nätverkssäkerhetsgrupp i undernätet.

DMZ. Överväg att lägga till en virtuell nätverksinstallation (NVA) för att skapa en DMZ mellan det offentliga Internet och det virtuella Azure-nätverket. NVA är ett allmänt begrepp för en virtuell installation som kan utföra nätverksrelaterade uppgifter, till exempel för brandväggen, paketinspektion, granskning och anpassad routning. Mer information finns i Implementera en DMZ mellan Azure och Internet.

Kryptering. Kryptera känsliga, vilande data och hantera krypteringsnycklar för databasen med Azure Key Vault. Key Vault kan lagra krypteringsnycklar i maskinvarusäkerhetsmoduler (HSM:er). Vi rekommenderar också att du lagrar programhemligheter, till exempel databas anslutningssträng s, i Key Vault.

DDoS-skydd. Azure-plattformen tillhandahåller grundläggande DDoS-skydd som standard. Det här grundläggande skyddet är avsett att skydda Azure-infrastrukturen som helhet. Även om grundläggande DDoS-skydd aktiveras automatiskt rekommenderar vi att du använder Azure DDoS Network Protection. Network Protection använder anpassningsbar justering, baserat på programmets nätverkstrafikmönster, för att identifiera hot. På så sätt kan den tillämpa åtgärder mot DDoS-attacker som kan gå obemärkt förbi de infrastrukturomfattande DDoS-principerna. Network Protection tillhandahåller även aviseringar, telemetri och analys via Azure Monitor. Mer information finns i Azure DDoS Protection: Metodtips och referensarkitekturer.

Driftsäkerhet

Eftersom alla huvudresurser och deras beroenden finns i samma virtuella nätverk i den här arkitekturen isoleras de i samma grundläggande arbetsbelastning. Det gör det enklare att associera arbetsbelastningens specifika resurser med ett DevOps-team, så att teamet oberoende kan hantera alla aspekter av dessa resurser. Den här isoleringen gör det möjligt för DevOps Teams och Services att utföra kontinuerlig integrering och kontinuerlig leverans (CI/CD).

Du kan också använda olika distributionsmallar och integrera dem med Azure DevOps Services för att etablera olika miljöer på några minuter, till exempel för att replikera produktion som scenarier eller belastningstestningsmiljöer endast när det behövs, vilket sparar kostnader.

I det här scenariot konfigureras dina virtuella datorer med hjälp av tillägg för virtuella datorer, eftersom de erbjuder möjligheten att installera vissa ytterligare program, till exempel Apache Cassandra. I synnerhet tillåter tillägget för anpassade skript nedladdning och körning av godtycklig kod på en virtuell dator, vilket tillåter obegränsad anpassning av operativsystemet för en virtuell Azure-dator. VM-tillägg installeras och körs endast när den virtuella datorn skapas. Det innebär att om operativsystemet konfigureras felaktigt i ett senare skede krävs en manuell åtgärd för att flytta tillbaka det till rätt tillstånd. Konfigurationshanteringsverktyg kan användas för att åtgärda det här problemet.

Överväg att använda Azure Monitor för att analysera och optimera prestanda för din infrastruktur samt övervaka och diagnostisera nätverksproblem utan att logga in på dina virtuella datorer. Application Insights är faktiskt en av komponenterna i Azure Monitor, vilket ger dig omfattande mått och loggar för att verifiera tillståndet för ditt fullständiga Azure-landskap. Azure Monitor hjälper dig att följa infrastrukturens tillstånd.

Se inte bara till att övervaka dina beräkningselement som stöder programkoden, utan även din dataplattform, särskilt dina databaser, eftersom en låg prestanda för datanivån i ett program kan få allvarliga konsekvenser.

För att testa Azure-miljön där programmen körs bör den vara versionskontrollerad och distribuerad via samma mekanismer som programkod, och sedan kan den testas och valideras med hjälp av DevOps-testparadigm också.

Mer information finns i avsnittet Operational Excellence i Microsoft Azure Well-Architecture Framework.

Nästa steg