Architettura della firma di accesso condiviso in Azure

Questa soluzione esegue carichi di lavoro di analisi della firma di accesso condiviso in Azure. Le linee guida illustrano vari scenari di distribuzione. Ad esempio, sono disponibili più versioni della firma di accesso condiviso. È possibile eseguire software sas in macchine virtuali (VM) autogestito. È anche possibile distribuire versioni basate su contenitori usando servizio Azure Kubernetes (servizio Azure Kubernetes).

Architettura

Scaricare un file di Visio di questa architettura.

Workflow

Le distribuzioni di Azure di firma di accesso condiviso in genere contengono tre livelli:

• Un livello API o di visualizzazione. All'interno di questo livello:

  • Il livello di metadati consente alle app client di accedere ai metadati su origini dati, risorse, server e utenti.
  • Le app Web forniscono l'accesso ai dati di intelligence nel livello intermedio.

• Piattaforma di calcolo, in cui i server sas elaborano i dati.

• Livello di archiviazione usato dalla firma di accesso condiviso per l'archiviazione permanente. Le scelte più comuni in Azure sono:

  • Lustro
  • IBM Spectrum Scale
  • File system di rete (NFS)

Un'Rete virtuale di Azure isola il sistema nel cloud. All'interno di tale rete:

• Un gruppo di posizionamento di prossimità riduce la latenza tra le macchine virtuali.
• I gruppi di sicurezza di rete proteggono le risorse di firma di accesso condiviso dal traffico indesiderato.

Prerequisiti

Prima di distribuire un carico di lavoro sas, verificare che siano presenti i componenti seguenti:

• Raccomandazione di dimensionamento da un team di ridimensionamento della firma di accesso condiviso
• Un file di licenza sas
• Accesso a un gruppo di risorse per la distribuzione delle risorse
• Una quota di sottoscrizione dell'unità di elaborazione centrale virtuale (vCPU) che tiene conto del documento di ridimensionamento e della scelta della macchina virtuale
• Accesso a un server LDAP (Lightweight Directory Access Protocol) sicuro

Dettagli dello scenario

Oltre a discutere diverse implementazioni, questa guida si allinea anche ai set di principi di Microsoft Azure Well-Architected Framework per ottenere l'eccellenza nelle aree di costo, DevOps, resilienza, scalabilità e sicurezza. Oltre a usare questa guida, consultare un team di firma di accesso condiviso per una convalida aggiuntiva del caso d'uso specifico.

Come partner, Microsoft e SAS stanno lavorando per sviluppare una roadmap per le organizzazioni che innovano nel cloud. Entrambe le aziende si impegnano a garantire distribuzioni di alta qualità di prodotti sas e soluzioni in Azure.

Introduzione alla firma di accesso condiviso

Il software di analisi della firma di accesso condiviso offre una suite di servizi e strumenti per ottenere informazioni dettagliate dai dati e prendere decisioni intelligenti. Le piattaforme SAS supportano completamente le soluzioni per aree come la gestione dei dati, il rilevamento delle frodi, l'analisi dei rischi e la visualizzazione. La firma di accesso condiviso offre queste piattaforme primarie, convalidate da Microsoft:

• Griglia SAS 9.4
• SAS Viya

Sono state testate le architetture seguenti:

• Griglia sas 9.4 in Linux
• SAS 9 Foundation
• SAS Viya 3.5 con architetture SMP (Symmetric MultiProcessing) e MPP (Massively Parallel Processing) in Linux
• SAS Viya 2020 e con un'architettura MPP nel servizio Azure Kubernetes

Questa guida fornisce informazioni generali per l'esecuzione della firma di accesso condiviso in Azure, non per informazioni specifiche della piattaforma. Queste linee guida presuppongono che si ospiti la propria soluzione di firma di accesso condiviso in Azure nel proprio tenant. La firma di accesso condiviso non ospita una soluzione in Azure. Per altre informazioni sui servizi di hosting e gestione di Azure forniti dalla firma di accesso condiviso, vedere Sas Managed Application Services (Servizi applicazioni gestite da firma di accesso condiviso).

Consigli

Quando si progetta l'implementazione, prendere in considerazione i punti nelle sezioni seguenti.

La documentazione della firma di accesso condiviso fornisce i requisiti per core, vale a dire per ogni core CPU fisico. Azure offre tuttavia elenchi di vCPU. Nelle macchine virtuali consigliate per l'uso con la firma di accesso condiviso sono disponibili due vCPU per ogni core fisico. Di conseguenza, per calcolare il valore di un requisito vCPU, usare metà del valore del requisito principale. Ad esempio, un requisito di core fisico di 150 MBps si traduce in 75 MBps per vCPU. Per altre informazioni sulle prestazioni di calcolo di Azure, vedere Unità di calcolo di Azure.For more information on Azure computing performance, see Azure compute unit (ACU).

Sistemi operativi

Linux funziona meglio per l'esecuzione di carichi di lavoro sas. Sas supporta le versioni a 64 bit dei sistemi operativi seguenti:

• Red Hat 7 o versione successiva
• SU edizione Standard Linux Enterprise Server (SLES) 12.2
• Oracle Linux 6 o versione successiva

Per altre informazioni sulle versioni di firma di accesso condiviso specifiche, vedere la matrice di supporto del sistema operativo SAS. Negli ambienti che usano più computer, è consigliabile eseguire la stessa versione di Linux in tutti i computer. Azure non supporta le distribuzioni a 32 bit di Linux.

Per ottimizzare la compatibilità e l'integrazione con Azure, iniziare con un'immagine del sistema operativo di Azure Marketplace. Se si usa un'immagine personalizzata senza configurazioni aggiuntive, può ridurre le prestazioni della firma di accesso condiviso.

Problemi del kernel

Quando si sceglie un sistema operativo, tenere presente un problema di blocco temporaneo che interessa l'intera serie di Red Hat 7.x. Si verifica in questi kernel:

• Kernel Linux 3.x
• Versioni precedenti alla 4.4

Un problema relativo alla gestione di memoria e I/O di Linux e Hyper-V causa il problema. Quando si tratta, i log di sistema contengono voci come questa che menzionano un interrupt non mascherabile (NMI):

Message from syslogd@ronieuwe-sas-e48-2 at Sep 13 08:26:08
kernel:NMI watchdog: BUG: soft lockup - CPU#12 stuck for 22s! [swapper/12:0]

Un altro problema riguarda le versioni precedenti di Red Hat. In particolare, può verificarsi nelle versioni che soddisfano queste condizioni:

• Avere kernel Linux che precedono 3.10.0-957.27.2
• Usare unità NVMe (Memory Express) non volatili

Quando il sistema riscontra un utilizzo elevato della memoria, il driver NVMe Linux generico potrebbe non allocare memoria sufficiente per un'operazione di scrittura. Di conseguenza, il sistema segnala un blocco flessibile che deriva da un deadlock effettivo.

Aggiornare il kernel per evitare entrambi i problemi. In alternativa, provare questa possibile soluzione alternativa:

• Impostare /sys/block/nvme0n1/queue/max_sectors_kb su 128 anziché usare il valore predefinito . 512
• Modificare questa impostazione in ogni dispositivo NVMe nella macchina virtuale e in ogni avvio della macchina virtuale.

Eseguire questi comandi per regolare questa impostazione:

# cat /sys/block/nvme0n1/queue/max_sectors_kb
512
# echo 128 >/sys/block/nvme0n1/queue/max_sectors_kb
# cat /sys/block/nvme0n1/queue/max_sectors_kb
128

Raccomandazioni per il dimensionamento delle macchine virtuali

Le distribuzioni di firma di accesso condiviso usano spesso gli SKU di macchina virtuale seguenti:

Serie Edsv5

Le macchine virtuali nella serie Edsv5 sono le macchine sas predefinite per Viya e Grid. Offrono queste funzionalità:

• Core vincolati. Con molti computer in questa serie, è possibile vincolare il numero di vCPU della macchina virtuale.
• Un buon rapporto tra CPU e memoria.
• Un disco collegato a livello locale a velocità effettiva elevata. La velocità di I/O è importante per le cartelle come SASWORK e la cache di Cloud Analytics Services ( CAS_CACHECAS), usata dalla firma di accesso condiviso per i file temporanei.

Se le macchine virtuali serie Edsv5 non sono disponibili, è consigliabile usare la generazione precedente. Le macchine virtuali serie Edsv4 sono state testate e sono state eseguite correttamente sui carichi di lavoro sas.

Serie Ebsv5

In alcuni casi, il disco collegato in locale non dispone di spazio di archiviazione sufficiente per SASWORK o CAS_CACHE. Per ottenere una directory di lavoro più grande, usare la serie Ebsv5 di macchine virtuali con dischi collegati Premium. Queste macchine virtuali offrono queste funzionalità:

• Stesse specifiche delle macchine virtuali Edsv5 e Esv5
• Velocità effettiva elevata rispetto al disco collegato remoto, fino a 4 GB/s, offrendo un SASWORK valore elevato o CAS_CACHE in base alle esigenze di I/O della firma di accesso condiviso.

Se le macchine virtuali serie Edsv5 offrono spazio di archiviazione sufficiente, è preferibile usarle in quanto sono più convenienti.

Serie M

Molti carichi di lavoro usano macchine virtuali serie M, tra cui:

• Implementazioni di SAS Programming Runtime Environment (SPRE) che usano un approccio Viya all'architettura software.
• Alcuni carichi di lavoro di Griglia di firma di accesso condiviso.

Le macchine virtuali serie M offrono queste funzionalità:

• Core vincolati
• Fino a 3,8 TiB di memoria, adatto per i carichi di lavoro che usano una grande quantità di memoria
• Velocità effettiva elevata per i dischi remoti, che funziona bene per la SASWORK cartella quando il disco disponibile in locale non è sufficiente

Serie Ls

Alcuni ambienti di I/O pesanti devono usare macchine virtuali serie Lsv2 o Lsv3 . In particolare, le implementazioni che richiedono velocità di I/O a bassa latenza e una grande quantità di memoria traggono vantaggio da questo tipo di computer. Gli esempi includono i sistemi che usano pesantemente la SASWORK cartella o CAS_CACHE.

Con Azure è possibile ridimensionare i sistemi Sas Viya su richiesta per soddisfare le scadenze:

• Aumentando la capacità di calcolo del pool di nodi.
• Usando il componente di scalabilità automatica del cluster del servizio Azure Kubernetes per aggiungere nodi e ridimensionare orizzontalmente.
• Aumentando temporaneamente l'infrastruttura per accelerare un carico di lavoro sas.

Con i carichi di lavoro Viya 3.5 e Grid, Azure non supporta al momento il ridimensionamento orizzontale o verticale. Viya 2022 supporta il ridimensionamento orizzontale.

Considerazioni sul posizionamento di rete e vm

I carichi di lavoro di firma di accesso condiviso sono spesso molto frequenti. Di conseguenza, possono trasferire una quantità significativa di dati. Con tutte le piattaforme di firma di accesso condiviso, seguire queste raccomandazioni per ridurre gli effetti del chatter:

• Distribuire piattaforme di firma di accesso condiviso e archiviazione nella stessa rete virtuale. Questo approccio evita inoltre di sostenere i costi di peering.
• Posizionare i computer SAS in un gruppo di posizionamento di prossimità per ridurre la latenza tra i nodi.
• Quando possibile, distribuire macchine virtuali e piattaforme di archiviazione dati basate su macchine virtuali nello stesso gruppo di posizionamento di prossimità.
• Distribuire appliance di firma di accesso condiviso e archiviazione nella stessa zona di disponibilità per evitare la latenza tra zone. Se non è possibile confermare che i componenti della soluzione vengono distribuiti nella stessa zona, contattare supporto tecnico di Azure.

La firma di accesso condiviso ha requisiti specifici per il nome di dominio completo (FQDN) per le macchine virtuali. Impostare correttamente i nomi di dominio completi del computer e assicurarsi che i servizi DNS (Domain Name System) funzionino. È possibile impostare i nomi con DNS di Azure. È anche possibile modificare il hosts file nella etc cartella di configurazione.

Quando si esegue la migrazione dei dati o si interagisce con la firma di accesso condiviso in Azure, è consigliabile usare una di queste soluzioni per connettere le risorse locali ad Azure:

• Un circuito Azure ExpressRoute
• Una rete privata virtuale (VPN)

Per i carichi di lavoro sas di produzione in Azure, ExpressRoute offre una connessione privata, dedicata e affidabile che offre questi vantaggi rispetto a una VPN da sito a sito:

• Maggiore velocità
• Latenza più bassa
• Maggiore sicurezza

Tenere presente le interfacce sensibili alla latenza tra applicazioni sas e non sas. Prendere in considerazione lo spostamento di origini dati e sink vicino alla firma di accesso condiviso.

Gestione delle identità

Le piattaforme sas possono usare account utente locali. Possono anche usare un server LDAP sicuro per convalidare gli utenti. È consigliabile eseguire un controller di dominio in Azure. Usare quindi la funzionalità di aggiunta al dominio per gestire correttamente l'accesso alla sicurezza. Se non sono stati configurati controller di dominio, valutare la possibilità di distribuire Microsoft Entra Domain Services (Microsoft Entra Domain Services). Quando si usa la funzionalità di aggiunta al dominio, assicurarsi che i nomi dei computer non superino il limite di 15 caratteri.

Origini dati

Le soluzioni sas spesso accedono ai dati da più sistemi. Queste origini dati rientrano in due categorie:

• Set di dati di firma di accesso condiviso archiviati nella SASDATA cartella
• Database in cui la firma di accesso condiviso spesso comporta un carico elevato

Per prestazioni ottimali:

• Posizionare le origini dati il più vicino possibile all'infrastruttura sas.
• Limitare il numero di hop di rete e appliance tra origini dati e infrastruttura di firma di accesso condiviso.

Archiviazione remota permanente per i dati di firma di accesso condiviso

Sas e Microsoft hanno testato una serie di piattaforme dati che è possibile usare per ospitare set di dati di firma di accesso condiviso. I blog sulla firma di accesso condiviso documentano in dettaglio i risultati, incluse le caratteristiche delle prestazioni. I test includono le piattaforme seguenti:

• Sycomp Archiviazione alimentato da IBM Spectrum Scale, che usa General Parallel File System (GPFS)
• EXAScaler Cloud by DataDirect Networks (DDN), basato sul file system Lustre
• Azure NetApp Files, che supporta i protocolli di archiviazione file NFS

Sas offre script di test delle prestazioni per le architetture Viya e Grid. I forum sulla firma di accesso condiviso forniscono documentazione sui test con script in queste piattaforme.

Sycomp Archiviazione alimentato da IBM Spectrum Scale (GPFS)

Per informazioni sul modo in cui Sycomp Archiviazione Fueled by IBM Spectrum Scale soddisfa le aspettative sulle prestazioni, vedere Revisione della firma di accesso condiviso di Sycomp for SAS Grid.

Per il ridimensionamento, Sycomp offre le raccomandazioni seguenti:

• Fornire un nodo di scalabilità GPFS per otto core con una configurazione di 150 MBps per core.
• Usare almeno cinque unità P30 per istanza.

DDN EXAScaler Cloud (Lustre)

DDN, che ha acquisito l'azienda Lustre di Intel, fornisce EXAScaler Cloud, basato sul file system parallelo Lustre. La soluzione è disponibile in Azure Marketplace come parte dell'ombrello DDN EXAScaler Cloud. Progettato per la distribuzione a elevato utilizzo di dati, offre una velocità effettiva elevata a basso costo.

I test mostrano che EXAScaler DDN può eseguire carichi di lavoro SAS in modo parallelo. DDN consiglia di eseguire questo comando in tutti i nodi client durante la distribuzione di EXAScaler o Lustre:

lctl set_param mdc.*.max_rpcs_in_flight=128 osc.*.max_pages_per_rpc=16M osc.*.max_rpcs_in_flight=16 osc.*.max_dirty_mb=1024 llite.*.max_read_ahead_mb=2048 osc.*.checksums=0  llite.*.max_read_ahead_per_file_mb=256

Azure NetApp Files (NFS)

I test di firma di accesso condiviso hanno convalidato le prestazioni di NetApp per griglia di firma di accesso condiviso. In particolare, i test mostrano che Azure NetApp Files è un'opzione di archiviazione primaria valida per i cluster di Griglia di firma di accesso condiviso con un massimo di 32 core fisici in più computer. Quando vengono usate ottimizzazioni e funzionalità Linux fornite da NetApp, Azure NetApp Files può essere l'opzione principale per i cluster fino a 48 core fisici in più computer.

Quando si usa questo servizio, tenere presente quanto segue:

• Azure NetApp Files funziona bene con le distribuzioni di Viya. Non usare Azure NetApp Files per la cache CAS in Viya, perché la velocità effettiva di scrittura non è adeguata. Se possibile, usare invece il disco temporaneo locale della macchina virtuale.
• In SAS 9 Foundation con Grid 9.4, le prestazioni di Azure NetApp Files con firma di accesso condiviso per SASDATA i file sono valide per i cluster fino a 32 core fisici. Questa operazione raggiunge fino a 48 core quando viene applicata l'ottimizzazione .
• Per garantire prestazioni ottimali, selezionare almeno un livello di servizio del livello di archiviazione Premium o Ultra durante la distribuzione di Azure NetApp Files. È possibile scegliere il livello di servizio Standard per volumi molto grandi. È consigliabile iniziare con il livello Premium e passare a Ultra o Standard in un secondo momento. Le modifiche a livello di servizio possono essere eseguite online, senza interruzioni o migrazioni di dati.
• Le prestazioni di lettura e scrittura sono diverse per Azure NetApp Files. La velocità effettiva di scrittura per sas raggiunge i limiti a circa 1600MiB/s mentre la velocità effettiva di lettura supera tale velocità, a circa 4500MiB/s. Se è necessaria una velocità effettiva di scrittura elevata continua, Azure NetApp Files potrebbe non essere adatto.

Altre origini dati

Le piattaforme SAS supportano varie origini dati:

• Un account azure Data Lake Archiviazione che usa uno spazio dei nomi gerarchico
• Azure Synapse Analytics
• Apache Hadoop e Hive in Azure HDInsight
• SQL Server
• SQL Server con Open Database Connessione ivity (ODBC)

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

L'output dei carichi di lavoro sas può essere uno degli asset critici dell'organizzazione. L'output della firma di accesso condiviso fornisce informazioni dettagliate sull'efficienza interna e può svolgere un ruolo fondamentale nella strategia di creazione di report. È quindi importante proteggere l'accesso all'architettura di firma di accesso condiviso. Per raggiungere questo obiettivo, usare l'autenticazione sicura e risolvere le vulnerabilità della rete. Usare la crittografia per proteggere tutti i dati in movimento e all'esterno dell'architettura.

Azure offre la firma di accesso condiviso usando un modello cloud IaaS (Infrastructure as a Service). Microsoft crea protezioni di sicurezza nel servizio ai livelli seguenti:

• Data center fisico
• Rete fisica
• Host fisico
• Hypervisor

Valutare attentamente i servizi e le tecnologie selezionati per le aree sopra l'hypervisor, ad esempio il sistema operativo guest per la firma di accesso condiviso. Assicurarsi di fornire i controlli di sicurezza appropriati per l'architettura.

La firma di accesso condiviso attualmente non supporta completamente Microsoft Entra ID. Per l'autenticazione nel livello di visualizzazione per la firma di accesso condiviso, è possibile usare Microsoft Entra ID. Per l'autorizzazione back-end, tuttavia, usare una strategia simile all'autenticazione locale. Quando si gestiscono le risorse IaaS, è possibile usare Microsoft Entra ID per l'autenticazione e l'autorizzazione per l'portale di Azure. Quando si usa Microsoft Entra Domain Services, non è possibile autenticare gli account guest. I tentativi guest di accesso avranno esito negativo.

Usare i gruppi di sicurezza di rete per filtrare il traffico di rete da e verso le risorse nella rete virtuale. Con questi gruppi è possibile definire regole che concedono o negano l'accesso ai servizi di firma di accesso condiviso. Alcuni esempi:

• Concedere l'accesso alle porte del ruolo di lavoro CAS da intervalli di indirizzi IP locali.
• Blocco dell'accesso ai servizi di firma di accesso condiviso da Internet.

È possibile usare Crittografia dischi di Azure per la crittografia all'interno del sistema operativo. Questa soluzione usa la funzionalità DM-Crypt di Linux. Attualmente, tuttavia, non è consigliabile usare Crittografia dischi di Azure. Può compromettere gravemente le prestazioni, soprattutto quando si usano SASWORK i file in locale.

La crittografia lato server (S edizione Standard) di Dischi di Azure Archiviazione protegge i dati. Consente inoltre di soddisfare gli impegni di sicurezza e conformità dell'organizzazione. Con i dischi gestiti di Azure, S edizione Standard crittografa i dati inattivi quando vengono mantenuti nel cloud. Questo comportamento si applica per impostazione predefinita sia ai dischi del sistema operativo che ai dischi dati. È possibile usare chiavi gestite dalla piattaforma o chiavi personalizzate per crittografare il disco gestito.

Proteggere l'infrastruttura

Controllare l'accesso alle risorse di Azure da distribuire. Ogni sottoscrizione di Azure ha una relazione di trust con un tenant di Microsoft Entra. Usare il Controllo degli accessi in base al ruolo di Azure per concedere agli utenti interni dell'organizzazione le autorizzazioni corrette per le risorse di Azure. Concedere l'accesso assegnando ruoli di Azure a utenti o gruppi in un determinato ambito. L'ambito può essere una sottoscrizione, un gruppo di risorse o una risorsa. Assicurarsi di controllare tutte le modifiche apportate all'infrastruttura.

Gestire l'accesso remoto alle macchine virtuali tramite Azure Bastion. Non esporre nessuno di questi componenti a Internet:

• Macchine virtuali
• Porte SSH (Secure Shell Protocol)
• Porte RDP (Remote Desktop Protocol)

Distribuire lo scenario

È consigliabile distribuire carichi di lavoro usando un processo IaC (Infrastructure as Code). I carichi di lavoro sas possono essere sensibili alle configurazioni errate che spesso si verificano nelle distribuzioni manuali e riducono la produttività.

Quando si compila l'ambiente, vedere materiale di riferimento di avvio rapido in CoreCompete SAS 9 o Viya in Azure.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Roeland): | Principal Cloud Solution Architect
• David Baumintune | Senior Cloud Solution Architect

Altro collaboratore:

• Drew Furgiuele | Senior Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Per informazioni introduttive, vedere le risorse seguenti:

• Implementare una rete ibrida sicura
• Macchine virtuali serie Edsv5
• Macchine virtuali serie Ebsv5
• Macchine virtuali serie Lsv3
• Gruppi di posizionamento di prossimità
• Zone di disponibilità di Azure

Per informazioni sul processo di automazione, vedere i modelli seguenti forniti dalla firma di accesso condiviso:

• SAS Viya 4 Infrastructure as Code
• Guida di SAS Viya 3.5
• Griglia SAS 9.4

Risorse correlate

• Azure Kubernetes nell'elaborazione del flusso di eventi
• GitOps per servizio Azure Kubernetes
• Monitorare un'architettura di microservizi in servizio Azure Kubernetes (servizio Azure Kubernetes)
• Gestione dei costi per Kubernetes
• Oracle Database con Azure NetApp Files
• SQL Server in macchine virtuali di Azure con Azure NetApp Files