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
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-lastbalanseraren 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 (Distributed Denial-of-Service) 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.
Hopplåda. 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. Hopprutan har en NSG som endast tillåter fjärrtrafik från offentliga IP-adresser i en säker lista. NSG:n bör tillåta RDP-trafik (Remote Desktop Protocol).
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 (classless inter-domain routing).] 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 har 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 programgatewayen.
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å.
- Neka all inkommande trafik från det virtuella nätverket. (Använd taggen
VIRTUAL_NETWORKi regeln.) - Tillåt inkommande trafik från undernätet på affärsnivå.
- 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.
- 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. All SSH-åtkomst till dessa virtuella datorer måste i stället gå via jumpbox. En administratör loggar in på jumpbox som sedan loggar in på den andra virtuella datorn från jumpbox. Jumpbox 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 jumpboxen 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 andra undernät så att SSH-trafik från hanteringsundernätet tillåts.
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Tillförlitlighet
Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i checklistan för Designgranskning för tillförlitlighet.
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.
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:
- Standard Load Balancer och tillgänglighetszoner
- Automatisk skalning och zonredundant Application Gateway v2
- Hur stöder Application Gateway hög tillgänglighet och skalbarhet?
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.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i checklistan för Designgranskning för Security.
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, såvida 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 Protection som standard. Det här grundläggande skyddet är avsett att skydda Azure-infrastrukturen som helhet. Även om grundläggande DDoS Protection 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.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för 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. REGLER för inkommande nätverksadressöversättning (NAT) är kostnadsfria. Standardlastbalanseraren debiteras inte varje timme när inga regler har konfigurerats.
Mer information finns i kostnadsavsnittet i Microsoft Azures välstrukturerade ramverk.
Operational Excellence
Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i checklistan för Designgranskning för Operational Excellence.
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, ö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.
Prestandaeffektivitet
Prestandaeffektivitet är arbetsbelastningens förmåga att uppfylla användarnas krav på det på ett effektivt sätt. Mer information finns i checklistan för Designgranskning för 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.