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:

  • Lustre
  • 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 a SAS

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:

• SAS Grid 9.4
• SAS Viya

Sono state sottoposte a test le architetture seguenti:

• Griglia sas 9.4 in Linux
• Fondazione SAS 9
• 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, tenere presenti 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 versioni successive
• SUSE Linux Enterprise Server (SLES) 12.2
• Oracle Linux 6 o successive

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. L'uso di un'immagine personalizzata senza configurazioni aggiuntive può ridurre le prestazioni di 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 verifica, i log di sistema contengono voci come questa che menzionano un interrupt non mascherabile :When it occurs, the system logs contain entries like this that mention a non-maskable interrupt (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
• Utilizzare drive NVMe (Non-Volatile Memory Express).

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

Consigli sul ridimensionamento VM

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 attualmente non supporta 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, è consigliabile distribuire 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 seguenti piattaforme:

• Sycomp Storage Fueled by IBM Spectrum Scale, che usa GpFS (General Parallel File System)
• Lustre gestito di Azure, che fornisce il file system parallelo Lustre
• Azure NetApp Files, che supporta i protocolli di archiviazione file NFS
• File di Azure Premium, ovvero un servizio di condivisione file che supporta il protocollo 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 Storage Fueled by IBM Spectrum Scale (GPFS)

Per informazioni sul modo in cui Sycomp Storage 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.

Managed Lustre di Azure

Azure Managed Lustre è un file system gestito creato per carichi di lavoro di elaborazione ad alte prestazioni (HPC) e intelligenza artificiale. Lustre gestito può eseguire carichi di lavoro SAS 9 e Viya in parallelo. Per ottimizzare le prestazioni del file system, seguire queste indicazioni:

• Quando si distribuisce Lustre gestito, eseguire l'ottimizzazione in tutti i nodi client per aumentare la lettura del client Lustre e ottimizzare la concorrenza per i modelli di I/O di firma di accesso condiviso. A tale scopo, usare il comando seguente:

  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
  

• abilitare la rete accelerata in tutte le macchine virtuali SAS.

• Per ridurre la latenza di rete, posizionare le macchine virtuali di firma di accesso condiviso nella stessa zona di disponibilità in cui viene distribuito Lustre gestito.

File di Azure (Premium)

File di Azure livello Premium è un servizio gestito che supporta il protocollo NFS 4.1. Offre un file system conveniente, elastico, efficiente e conforme a POSIX. Le operazioni di I/O al secondo e la velocità effettiva delle condivisioni NFS vengono ridimensionate in base alla capacità di cui è stato effettuato il provisioning. La firma di accesso condiviso ha testato ampiamente il livello Premium di File di Azure e ha rilevato che le prestazioni sono più che sufficienti per alimentare le installazioni sas.

Usare nconnect per migliorare le prestazioni. Questa opzione di montaggio distribuisce le richieste di I/O su più canali. Per altre informazioni, vedere Prestazioni NFS.

Quando si usa una condivisione file di Azure NFS in File di Azure, considerare i punti seguenti:

• Modificare la capacità di cui è stato effettuato il provisioning per soddisfare i requisiti di prestazioni. Le operazioni di I/O al secondo e la velocità effettiva delle condivisioni NFS vengono ridimensionate in base alla capacità di cui è stato effettuato il provisioning. Per altre informazioni, vedere Prestazioni NFS.
• Usare nConnect nei montaggi con un'impostazione di nconnect=4 per l'uso di canali paralleli con prestazioni ottimali.
• Ottimizzare le impostazioni di read-ahead per essere 15 volte su rsize e wsize. Per la maggior parte dei carichi di lavoro, è consigliabile usare e rsizewsize 1 MB e un'impostazione read-ahead di 15 MB. Per altre informazioni, vedere Aumentare le dimensioni read-ahead.

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 le ottimizzazioni fornite da NetApp e le funzionalità Linux, Azure NetApp Files può essere l'opzione principale per i cluster fino a 48 core fisici in più computer.

Quando si usa questo servizio, è opportuno considerare i punti seguenti:

• 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. Questo aumenta 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 differiscono per Azure NetApp Files. La velocità effettiva di scrittura per sas raggiunge i limiti a circa 1600 MiB/s, mentre la velocità effettiva di lettura supera tale limite, a circa 4500 MiB/s. Se è necessaria una velocità effettiva di scrittura elevata continua, Azure NetApp Files potrebbe non essere adatto.

Ottimizzazione read-ahead di NFS

Per migliorare le prestazioni del carico di lavoro sas, è importante ottimizzare l'impostazione del read-ahead kernel, che influisce sul modo in cui vengono montate le condivisioni NFS. Quando è abilitato read-ahead, il kernel Linux può richiedere blocchi prima di qualsiasi I/O effettivo dall'applicazione. Il risultato è stato migliorato nella velocità effettiva di lettura sequenziale. La maggior parte dei carichi di lavoro sas legge molti file di grandi dimensioni per un'ulteriore elaborazione, quindi la firma di accesso condiviso offre enormi vantaggi dai buffer read-ahead di grandi dimensioni.

Con i kernel Linux 5.4 o versioni successive, il valore predefinito di read-ahead è cambiato da 15 MB a 128 KB. Il nuovo valore predefinito riduce le prestazioni di lettura per la firma di accesso condiviso. Per ottimizzare le prestazioni, aumentare l'impostazione read-ahead nelle macchine virtuali Linux sas. Firma di accesso condiviso e Microsoft consiglia di impostare read-ahead su 15 volte e rsizewsize. Idealmente, rsize e wsize sono entrambi 1 MB e read-ahead è 15 MB.

L'impostazione di read-ahead in una macchina virtuale è semplice. Richiede l'aggiunta di una regola udev.

Per Kubernetes, questo processo è più complesso perché deve essere eseguito nell'host e non nel pod. La firma di accesso condiviso fornisce script per Viya nel servizio Azure Kubernetes che imposta automaticamente il valore read-ahead nel post. Per altre informazioni, vedere Uso di condivisioni NFS Premium in File di Azure per SAS Viya in Kubernetes.

Altre origini dati

Le piattaforme SAS supportano varie origini dati:

• Un account di Azure Data Lake Storage che usa uno spazio dei nomi gerarchico
• Azure Synapse Analytics
• Apache Hadoop e Hive in Azure HDInsight
• SQL Server
• SQL Server con Odbc (Open Database Connectivity)

Considerazioni

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

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 che si spostano all'esterno e all'esterno dell'architettura.

SAS in Azure viene offerto tramite il modello cloud IaaS (Infrastructure-as-a-Service, infrastruttura distribuita come servizio). 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 SAS. 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 propria rete virtuale. Con questi gruppi è possibile definire regole che concedono o negano l'accesso ai servizi SAS. 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 di Archiviazione su disco di Azure protegge i dati. Consente inoltre di soddisfare gli impegni di sicurezza e conformità dell'organizzazione. Con i dischi gestiti di Azure, SSE 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 Remote Desktop Protocol (RDP)

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 il 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): | Capo architetto
• David Baumintune | Architetto principale

Altri contributori:

• Drew Furgiuele | Senior Architect

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

Passaggi successivi

Per assistenza all'avvio rapido, consultare le risorse seguenti:

• Implementare una rete ibrida sicura
• Macchine virtuali serie EdSv5
• Macchine virtuali serie Ebsv5
• Maccbhine virtuali serie Lsv3
• Gruppi di posizionamento di prossimità
• Zone di disponibilità di Azure
• Migliorare le prestazioni della condivisione file NFS 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
• SAS 9.4 Grid

Risorse correlate

• Azure Kubernetes nell'elaborazione del flusso di eventi
• GitOps per il 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