Linux
Suggerisci modifiche
PDF
Argomenti di configurazione specifici del sistema operativo Linux.
Tabelle degli slot TCP per Linux NFSv3
Le tabelle degli slot TCP sono l'equivalente di NFSv3 della profondità della coda degli HBA (host Bus Adapter). Queste tabelle controllano il numero di operazioni NFS che possono essere in sospeso in qualsiasi momento. Il valore predefinito è di solito 16, che è troppo basso per ottenere prestazioni ottimali. Il problema opposto si verifica sui kernel Linux più recenti, che possono aumentare automaticamente il limite della tabella degli slot TCP a un livello che satura il server NFS con le richieste.
Per prestazioni ottimali e per evitare problemi di prestazioni, regolare i parametri del kernel che controllano le tabelle degli slot TCP.
Eseguire sysctl -a | grep tcp.*.slot_table e osservare i seguenti parametri:
# sysctl -a | grep tcp.*.slot_table sunrpc.tcp_max_slot_table_entries = 128 sunrpc.tcp_slot_table_entries = 128
Tutti i sistemi Linux dovrebbero includere sunrpc.tcp_slot_table_entries, ma solo alcuni includono sunrpc.tcp_max_slot_table_entries. Entrambi devono essere impostati su 128.
| Attenzione |
|---|
La mancata impostazione di questi parametri può avere effetti significativi sulle prestazioni. In alcuni casi, le prestazioni sono limitate poiché il sistema operativo linux non fornisce i/o sufficienti In altri casi, le latenze i/o aumentano quando il sistema operativo linux tenta di emettere più i/o di quanto possa essere gestito. |
Opzioni di montaggio NFS Linux
Nella tabella seguente sono elencate le opzioni di montaggio NFS Linux per una singola istanza.
| Tipo di file | Opzioni di montaggio |
|---|---|
Pagina iniziale ADR |
|
File di controllo File di dati Registri di ripristino |
|
ORACLE_HOME |
|
Nella tabella seguente sono elencate le opzioni di montaggio NFS Linux per RAC.
| Tipo di file | Opzioni di montaggio |
|---|---|
Pagina iniziale ADR |
|
File di controllo File di dati Registri di ripristino |
|
CRS/votazione |
|
Dedicato |
|
Condiviso |
|
L'aggiunta fa la differenza principale tra le opzioni di montaggio RAC e a istanza singola actimeo=0 alle opzioni di montaggio. Questa aggiunta ha l'effetto di disabilitare il caching del sistema operativo host, consentendo a tutte le istanze nel cluster RAC di avere una visione coerente dello stato dei dati. Anche se si utilizza il init.ora parametro filesystemio_options=setall ha lo stesso effetto di disabilitare la cache dell'host, è comunque necessario utilizzare actimeo=0.
Il motivo actimeo=0 è obbligatorio per condiviso ORACLE_HOME Le distribuzioni consentono di semplificare la coerenza di file quali file di password e file spfile di Oracle. Se ogni istanza di un cluster RAC dispone di un'istanza dedicata ORACLE_HOME, questo parametro non è necessario.
In genere, i file non di database devono essere montati con le stesse opzioni utilizzate per i file di dati a singola istanza, sebbene applicazioni specifiche possano avere requisiti diversi. Evitare le opzioni di montaggio noac e. actimeo=0 se possibile perché queste opzioni disabilitano la lettura e il buffering a livello di file system. Ciò può causare gravi problemi di prestazioni per processi quali l'estrazione, la traduzione e il caricamento.
ACCESSO e GETATTR
Alcuni clienti hanno notato che un livello estremamente elevato di altri IOPS, come ACCESSO e GETATTR, può dominare i propri workload. In casi estremi, operazioni come letture e scritture possono arrivare fino al 10% del totale. Si tratta di un comportamento normale con qualsiasi database che include l'uso di actimeo=0 e/o. noac Su Linux perché queste opzioni fanno sì che il sistema operativo Linux ricarichi costantemente i metadati dei file dal sistema di archiviazione. Operazioni quali ACCESS e GETATTR sono operazioni a basso impatto gestite dalla cache ONTAP in un ambiente di database. Non dovrebbero essere considerati IOPS autentici, come le letture e le scritture, che creano una vera domanda sui sistemi storage. Tuttavia, questi altri IOPS creano un certo carico, specialmente negli ambienti RAC. Per risolvere questo problema, abilitare DNFS, che ignora la cache buffer del sistema operativo ed evita queste operazioni non necessarie relative ai metadati.
Linux Direct NFS
Un'opzione di montaggio aggiuntiva, denominata nosharecache, È necessario quando (a) DNFS è abilitato e (b) un volume sorgente è montato più di una volta su un singolo server (c) con un mount NFS nidificato. Questa configurazione si osserva principalmente in ambienti che supportano applicazioni SAP. Ad esempio, un singolo volume di un sistema NetApp può avere una directory situata in /vol/oracle/base e un secondo a. /vol/oracle/home. Se /vol/oracle/base è montato su /oracle e. /vol/oracle/home è montato su /oracle/home, Il risultato sono montaggi NFS nidificati che hanno origine sulla stessa fonte.
Il sistema operativo è in grado di rilevare che /oracle e /oracle/home si trovano sullo stesso volume, che è lo stesso file system di origine. Il sistema operativo utilizza quindi lo stesso handle di dispositivo per l'accesso ai dati. In questo modo si migliora l'uso della cache del sistema operativo e di alcune altre operazioni, ma interferisce con DNFS. Se DNFS deve accedere a un file, come ad esempio spfile , on , /oracle/home potrebbe erroneamente tentare di utilizzare il percorso errato dei dati. Il risultato è un'operazione i/o non riuscita. In queste configurazioni, Aggiungi l' `nosharecache`opzione di montaggio a qualsiasi file system NFS che condivide un volume di origine con un altro file system NFS su quell'host. In questo modo, il sistema operativo Linux assegna un handle di dispositivo indipendente al file system.
Linux Direct NFS e Oracle RAC
L'uso di DNFS offre speciali vantaggi in termini di prestazioni per Oracle RAC sul sistema operativo Linux, poiché Linux non dispone di un metodo per forzare l'i/o diretto, necessario con RAC per la coerenza tra i nodi. Come soluzione, Linux richiede l'uso di actimeo=0 Opzione di montaggio, che fa sì che i dati dei file scadano immediatamente dalla cache del sistema operativo. Questa opzione a sua volta obbliga il client NFS Linux a rileggere costantemente i dati degli attributi, danneggiando la latenza e aumentando il carico sullo storage controller.
Abilitando DNFS si ignora il client NFS dell'host ed evita questo danno. Diversi clienti hanno segnalato significativi miglioramenti delle performance sui cluster RAC e una significativa riduzione del carico ONTAP (soprattutto in relazione ad altri IOPS) quando si attiva DNFS.
Linux Direct NFS e file oranfstab
Quando si utilizza DNFS su Linux con l'opzione multipathing, è necessario utilizzare più sottoreti. Su altri sistemi operativi, è possibile stabilire più canali DNFS utilizzando LOCAL e. DONTROUTE Opzioni per configurare più canali DNFS su una singola subnet. Tuttavia, questo non funziona correttamente su Linux e possono verificarsi problemi di prestazioni imprevisti. Con Linux, ogni NIC utilizzata per il traffico DNFS deve trovarsi su una subnet diversa.
Utilità di pianificazione i/O.
Il kernel Linux permette un controllo di basso livello sul modo in cui l'i/o blocca i dispositivi è programmato. Le impostazioni predefinite su varie distribuzioni di Linux variano notevolmente. I test dimostrano che la scadenza di solito offre i migliori risultati, ma a volte NOOP è stato leggermente migliore. La differenza di prestazioni è minima, ma è necessario verificare entrambe le opzioni se è necessario estrarre le massime prestazioni possibili da una configurazione di database. CFQ è l'impostazione predefinita in molte configurazioni e ha dimostrato di avere problemi significativi di prestazioni con i carichi di lavoro del database.
Per istruzioni sulla configurazione dello scheduler i/o, consultare la documentazione del fornitore di Linux pertinente.
Multipathing
Alcuni clienti hanno riscontrato arresti anomali durante l'interruzione della rete perché il daemon multipath non era in esecuzione sul proprio sistema. Nelle versioni recenti di Linux, il processo di installazione del sistema operativo e del demone multipathing potrebbero lasciare questi sistemi operativi vulnerabili a questo problema. I pacchetti sono installati correttamente, ma non sono configurati per l'avvio automatico dopo un riavvio.
Ad esempio, il valore predefinito per il daemon multipath su RHEL5,5 potrebbe essere il seguente:
[root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Questo può essere corretto con i seguenti comandi:
[root@host1 iscsi]# chkconfig multipathd on [root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Mirroring ASM
Il mirroring ASM potrebbe richiedere modifiche alle impostazioni di multipath Linux per consentire ad ASM di riconoscere un problema e passare a un gruppo di errori alternativo. La maggior parte delle configurazioni ASM su ONTAP utilizza la ridondanza esterna, il che significa che la protezione dei dati è fornita dall'array esterno e ASM non esegue il mirroring dei dati. Alcuni siti utilizzano ASM con ridondanza normale per fornire il mirroring bidirezionale, in genere su siti diversi.
Le impostazioni di Linux visualizzate nella "Documentazione delle utilità host NetApp" Includi parametri multipath che determinano indefinite code di i/O. Ciò significa che un i/o su un dispositivo LUN senza percorsi attivi attende finché l'i/o non viene completato. Questo è solitamente consigliabile perché gli host Linux attendono il tempo necessario per il completamento delle modifiche al percorso SAN, per il riavvio degli switch FC o per il completamento di un failover da parte di un sistema di storage.
Questo comportamento di accodamento illimitato causa un problema con il mirroring ASM perché ASM deve ricevere un errore di i/o per consentire al reparto IT di riprovare l'i/o su un LUN alternativo.
Impostare i seguenti parametri in Linux multipath.conf File per i LUN ASM utilizzati con il mirroring ASM:
polling_interval 5 no_path_retry 24
Queste impostazioni creano un timeout di 120 secondi per i dispositivi ASM. Il timeout viene calcolato come polling_interval * no_path_retry in pochi secondi. In alcuni casi potrebbe essere necessario regolare il valore esatto, ma per la maggior parte degli utilizzi dovrebbe essere sufficiente un timeout di 120 secondi. In particolare, 120 secondi devono consentire il takeover o il giveback del controller senza produrre un errore di i/o che porterebbe il gruppo guasto a diventare offline.
Un più basso no_path_retry Il valore può ridurre il tempo richiesto per ASM per passare a un gruppo di errori alternativo, ma aumenta anche il rischio di un failover indesiderato durante attività di manutenzione come il takeover di un controller. Il rischio può essere mitigato tramite un attento monitoraggio dello stato di mirroring ASM. Se si verifica un failover indesiderato, è possibile risincronizzare rapidamente i mirror se la risincronizzazione viene eseguita in modo relativamente rapido. Per ulteriori informazioni, consultare la documentazione Oracle su ASM Fast Mirror Resync per la versione del software Oracle in uso.
Linux xfs, ext3, e ext4 opzioni di mount
|
NetApp recommended usando le opzioni di mount predefinite. |