Dela via

Välj en Azure-målplattform som värd för exporterade historiska data

  • Artikel

Ett av de viktiga beslut du fattar under migreringsprocessen är var du ska lagra dina historiska data. För att fatta det här beslutet måste du förstå och kunna jämföra de olika målplattformarna.

Den här artikeln jämför målplattformar när det gäller prestanda, kostnad, användbarhet och hanteringskostnader.

Anteckning

Övervägandena i den här tabellen gäller endast för migrering av historiska loggar och gäller inte i andra scenarier, till exempel långsiktig kvarhållning.

Grundläggande loggar/arkiv Azure Data Explorer (ADX) Azure Blob Storage ADX + Azure Blob Storage
Funktioner: • Tillämpa de flesta av de befintliga Azure Monitor-loggarna till en lägre kostnad.
• Grundläggande loggar bevaras i åtta dagar och överförs sedan automatiskt till arkivet (enligt den ursprungliga kvarhållningsperioden).
• Använd sökjobb för att söka i petabyte med data och hitta specifika händelser.
• För djupgående undersökningar av ett visst tidsintervall kan du återställa data från arkivet. Data är sedan tillgängliga i frekvent cache för ytterligare analys.		 • Både ADX och Microsoft Sentinel använder Kusto-frågespråk (KQL), så att du kan fråga, aggregera eller korrelera data på båda plattformarna. Du kan till exempel köra en KQL-fråga från Microsoft Sentinel för att ansluta data som lagras i ADX med data som lagras i Log Analytics.
• Med ADX har du stor kontroll över klusterstorleken och konfigurationen. Du kan till exempel skapa ett större kluster för att uppnå högre dataflöde för inmatning eller skapa ett mindre kluster för att kontrollera dina kostnader.		 • Bloblagring är optimerat för lagring av enorma mängder ostrukturerade data.
• Erbjuder konkurrenskraftiga kostnader.
• Lämplig för ett scenario där din organisation inte prioriterar tillgänglighet eller prestanda, till exempel när organisationen måste anpassa sig till efterlevnads- eller granskningskrav.		 • Data lagras i en bloblagring, vilket är lågt i kostnader.
• Du använder ADX för att köra frågor mot data i KQL, så att du enkelt kan komma åt data. Lär dig hur du kör frågor mot Azure Monitor-data med ADX
Användbarhet: Suveränt

Arkiv- och sökalternativen är enkla att använda och tillgängliga från Microsoft Sentinel-portalen. Data är dock inte omedelbart tillgängliga för frågor. Du måste utföra en sökning för att hämta data, vilket kan ta lite tid, beroende på hur mycket data som genomsöks och returneras.		 Bra

Ganska lätt att använda i samband med Microsoft Sentinel. Du kan till exempel använda en Azure-arbetsbok för att visualisera data som är spridda över både Microsoft Sentinel och ADX. Du kan också köra frågor mot ADX-data från Microsoft Sentinel-portalen med hjälp av ADX-proxyn.		 Dålig

Med historiska datamigreringar kan du behöva hantera miljontals filer, och att utforska data blir en utmaning.		 Ganska bra

Även om det är mycket svårt att använda operatorn externaldata med ett stort antal blobar att referera till, eliminerar användningen av externa ADX-tabeller det här problemet. Den externa tabelldefinitionen förstår strukturen för bloblagringsmappen och gör att du transparent kan fråga efter data som finns i många olika blobbar och mappar.
Hanteringskostnader: Fullständigt hanterad

Sök- och arkivalternativen hanteras fullständigt och lägger inte till hanteringskostnader.		 Hög

ADX är externt för Microsoft Sentinel, vilket kräver övervakning och underhåll.		 Låg

Även om den här plattformen kräver lite underhåll lägger valet av den här plattformen till övervaknings- och konfigurationsuppgifter, till exempel att konfigurera livscykelhantering.		 Medel

Med det här alternativet underhåller och övervakar du ADX och Azure Blob Storage, som båda är externa komponenter till Microsoft Sentinel. Även om ADX kan stängas av ibland bör du överväga extra hanteringskostnader med det här alternativet.
Prestanda: Medel

Du interagerar vanligtvis med grundläggande loggar i arkivet med hjälp av sökjobb, vilket är lämpligt när du vill behålla åtkomsten till data, men inte behöver omedelbar åtkomst till data.		 Högt till lågt

• Frågeprestandan för ett ADX-kluster beror på antalet noder i klustret, den virtuella klusterdatorns SKU, datapartitionering med mera.
• När du lägger till noder i klustret förbättras prestandan med extra kostnad.
• Om du använder ADX rekommenderar vi att du konfigurerar klusterstorleken för att balansera prestanda och kostnader. Den här konfigurationen beror på organisationens behov, inklusive hur snabbt migreringen behöver slutföras, hur ofta data används och förväntad svarstid.		 Låg

Erbjuder två prestandanivåer: Premium eller Standard. Även om båda nivåerna är ett alternativ för långsiktig lagring är Standard mer kostnadseffektivt. Lär dig mer om prestanda- och skalbarhetsgränser.		 Låg

Eftersom data finns i Blob Storage begränsas prestandan av den plattformen.
Kostnad: Hög

Kostnaden består av två komponenter:
• Inmatningskostnad. Alla GB data som matas in i grundläggande loggar omfattas av inmatningskostnader för Microsoft Sentinel- och Azure Monitor-loggar, som uppgår till cirka 1 USD/GB. Se prisinformationen.
• Arkiveringskostnad. Kostnaden för data på arkivnivån uppgår till cirka 0,02 USD/GB per månad. Se prisinformationen.
Utöver dessa två kostnadskomponenter gäller extra kostnader när du kommer åt data via sökjobb om du behöver frekvent åtkomst till data.		 Högt till lågt

• Eftersom ADX är ett kluster med virtuella datorer debiteras du baserat på beräknings-, lagrings- och nätverksanvändning, plus en ADX-markering (se prisinformationen. Ju fler noder du lägger till i klustret och ju mer data du lagrar desto högre blir kostnaden.
• ADX erbjuder även funktioner för automatisk skalning för att anpassa sig till arbetsbelastning på begäran. ADX kan också dra nytta av prissättningen för reserverad instans. Du kan köra dina egna kostnadsberäkningar i Priskalkylatorn för Azure.		 Låg

Med optimal konfiguration har Azure Blob Storage de lägsta kostnaderna. För större effektivitet och kostnadsbesparingar kan livscykelhantering i Azure Storage användas för att automatiskt placera äldre blobar i billigare lagringsnivåer.		 Låg

ADX fungerar bara som proxy i det här fallet, så klustret kan vara litet. Dessutom kan klustret stängas av när du inte behöver åtkomst till data och bara starta det när dataåtkomst behövs..
Så här kommer du åt data: Sök jobb Direkta KQL-frågor externaldata Ändrade KQL-frågor
Scenario: Tillfällig åtkomst

Relevant i scenarier där du inte behöver köra tunga analys- eller utlösaranalysregler, och du bara behöver komma åt data ibland.		 Frekvent åtkomst

Relevant i scenarier där du behöver komma åt data ofta och behöver styra hur klustret är storleksanpassat och konfigurerat.		 Efterlevnad/granskning

• Optimalt för lagring av stora mängder ostrukturerade data.
• Relevant i scenarier där du inte behöver snabb åtkomst till data eller höga prestanda, till exempel i efterlevnads- eller granskningssyfte.		 Tillfällig åtkomst

Relevant i scenarier där du vill dra nytta av den låga kostnaden för Azure Blob Storage och upprätthålla relativt snabb åtkomst till data.
Komplexitet: Mycket låg Medel Låg Högt
Beredskap: Allmän tillgänglighet (GA) Allmän tillgänglighet (GA) Allmän tillgänglighet (GA) Allmän tillgänglighet (GA)

Generella saker att tänka på

Nu när du vet mer om de tillgängliga målplattformarna kan du gå igenom de här huvudfaktorerna för att slutföra ditt beslut.

Användning av inmatade loggar

Definiera hur din organisation ska använda de inmatade loggarna för att vägleda ditt val av inmatningsplattform.

Tänk på följande tre allmänna scenarier:

  • Din organisation behöver endast behålla loggarna i efterlevnads- eller granskningssyfte. I det här fallet kommer din organisation sällan åt data. Även om din organisation har åtkomst till data prioriteras inte höga prestanda eller användarvänlighet.
  • Din organisation måste behålla loggarna så att dina team enkelt och ganska snabbt kan komma åt loggarna.
  • Din organisation måste behålla loggarna så att dina team kan komma åt loggarna ibland. Prestanda och användarvänlighet är sekundära.

Se plattformsjämförelsen för att förstå vilken plattform som passar var och en av dessa scenarier.

Migreringshastighet

I vissa scenarier kan du behöva uppfylla en snäv tidsgräns, till exempel kan din organisation snabbt behöva flytta från den tidigare SIEM på grund av en licens förfallohändelse.

Granska de komponenter och faktorer som avgör hastigheten för migreringen.

Datakälla

Datakällan är vanligtvis ett lokalt filsystem eller molnlagring, till exempel S3. En servers lagringsprestanda beror på flera faktorer, till exempel diskteknik (SSD jämfört med HDD), typen av I/O-begäranden och storleken på varje begäran.

Prestanda för virtuella Azure-datorer varierar till exempel från 30 MB per sekund på mindre VM-SKU:er till 20 GB per sekund för några av de lagringsoptimerade SKU:erna med NVM Express-diskar (NVMe). Lär dig hur du utformar din virtuella Azure-dator för höga lagringsprestanda. Du kan också använda de flesta begrepp på lokala servrar.

Beräkningskraft

I vissa fall, även om disken kan kopiera dina data snabbt, är beräkningskraft flaskhalsen i kopieringsprocessen. I dessa fall kan du välja ett av följande skalningsalternativ:

  • Skala lodrätt. Du ökar kraften hos en enskild server genom att lägga till fler processorer eller öka processorhastigheten.
  • Skala vågrätt. Du lägger till fler servrar, vilket ökar kopieringsprocessens parallellitet.

Målplattform

Var och en av de målplattformar som beskrivs i det här avsnittet har olika prestandaprofiler.

  • Azure Monitor Basic-loggar. Som standard kan Grundläggande loggar skickas till Azure Monitor med en hastighet på cirka 1 GB per minut. Med den här hastigheten kan du mata in cirka 1,5 TB per dag eller 43 TB per månad.
  • Azure Data Explorer. Inmatningsprestanda varierar beroende på storleken på klustret som du etablerar och de batchinställningar som du tillämpar. Lär dig mer om metodtips för inmatning, inklusive prestanda och övervakning.
  • Azure Blob Storage. Prestandan för ett Azure Blob Storage konto kan variera kraftigt beroende på antalet och storleken på filerna, jobbstorleken, samtidigheten och så vidare. Lär dig hur du optimerar AzCopy-prestanda med Azure Storage.

Mängden data

Mängden data är den viktigaste faktorn som påverkar migreringsprocessens varaktighet. Du bör därför överväga hur du konfigurerar din miljö beroende på din datauppsättning.

Om du vill fastställa den minsta varaktigheten för migreringen och var flaskhalsen kan vara bör du överväga mängden data och inmatningshastigheten för målplattformen. Du kan till exempel välja en målplattform som kan mata in 1 GB per sekund och du måste migrera 100 TB. I det här fallet tar migreringen minst 100 000 GB, multiplicerat med hastigheten 1 GB per sekund. Dividera resultatet med 3600, vilket beräknas till 27 timmar. Den här beräkningen är korrekt om resten av komponenterna i pipelinen, till exempel den lokala disken, nätverket och de virtuella datorerna, kan utföras med en hastighet av 1 GB per sekund.

Nästa steg

I den här artikeln har du lärt dig hur du mappar dina migreringsregler från QRadar till Microsoft Sentinel.

Välj ett datainmatningsverktyg