Skip to main content
Enterprise applications
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

MySQL con SAN

Collaboratori

Esistono due opzioni per configurare MySQL con SAN utilizzando il solito modello a due volumi.

È possibile collocare database di dimensioni inferiori su una coppia di LUN standard, a condizione che le richieste di i/o e capacità rientrino nei limiti di un singolo file system LUN. Ad esempio, un database che richiede circa 2K IOPS casuali può essere ospitato su un singolo file system su un singolo LUN. Analogamente, un database di sole 100GB GB di dimensioni dovrebbe adattarsi a un singolo LUN, senza creare problemi di gestione.

Database di dimensioni maggiori richiedono LUN multiple. Ad esempio, un database che richiede 100K IOPS avrà probabilmente bisogno di almeno otto LUN. Un singolo LUN sarebbe diventato un collo di bottiglia a causa del numero inadeguato di canali SCSI per le unità. Analogamente, sarebbe difficile gestire un database da 10TB TB su un singolo LUN da 10TB GB. I gestori di volumi logici sono progettati per unire le funzionalità di performance e capacità di più LUN per migliorare le prestazioni e la gestibilità.

In entrambi i casi, dovrebbe essere sufficiente una coppia di ONTAP Volumes. Con una configurazione semplice, la LUN dei file di dati viene posizionata in un volume dedicato, come farebbe la LUN di log. Con una configurazione di volume manager logica, tutte le LUN del gruppo di volumi dei file di dati si troverebbero in un volume dedicato e le LUN del gruppo di volumi di log si troverebbero in un secondo volume dedicato.

Suggerimento

NetApp consiglia di utilizzare due file system per le distribuzioni MySQL su SAN:

  • Il primo file system memorizza tutti i dati MySQL inclusi tablespace, dati e indice.

  • Il secondo file system archivia tutti i log (log binari, log lenti e log delle transazioni).

Esistono diverse ragioni per separare i dati in questo modo, tra cui:

  • I modelli di i/o dei file di dati e di registro sono diversi. La loro separazione permetterebbe più opzioni con i controlli QoS.

  • L'uso ottimale della tecnologia Snapshot richiede la capacità di ripristinare in maniera indipendente i file di dati. L'associazione di file di dati con file di registro interferisce con il ripristino dei file di dati.

  • La tecnologia NetApp SnapMirror può essere utilizzata per fornire una semplice funzionalità di disaster recovery con RPO ridotto per un database; tuttavia, richiede diverse pianificazioni della replica per i file di dati e log.
Nota Utilizzare questo layout di base a due volumi per rendere la soluzione a prova di futuro, in modo che tutte le funzioni di ONTAP possano essere utilizzate se necessario.
Suggerimento

NetApp consiglia la formattazione dell'unità con il file system ext4, grazie alle seguenti funzioni:

  • Approccio esteso alle funzioni di gestione dei blocchi utilizzate nel file system di journaling (JFS) e nelle funzioni di allocazione differita del file system esteso (XFS).

  • ext4 permette file system fino a 1 exbibyte (2^60 byte) e file fino a 16 tebibyte (16 * 2^40 byte). Al contrario, il file system ext3 supporta solo file system di dimensioni massime pari a 16TB MB e file di dimensioni massime pari a 2TB MB.

  • Nei file system ext4, l'allocazione di più blocchi (mballoc) alloca più blocchi per un file in un'unica operazione, invece di assegnarli uno alla volta, come in ext3. Questa configurazione riduce l'overhead di chiamata dell'allocatore di blocchi diverse volte e ottimizza l'allocazione di memoria.

  • Anche se XFS è il default per molte distribuzioni Linux, gestisce i metadati in modo diverso e non è adatto per alcune configurazioni MySQL.
Suggerimento

NetApp consiglia di utilizzare le opzioni di dimensione del blocco 4K con l'utilità mkfs per allinearsi alle dimensioni del LUN del blocco esistenti.

mkfs.ext4 -b 4096

Le LUN NetApp memorizzano dati in blocchi fisici da 4KB KB, ottenendo otto blocchi logici da 512 byte.

Se non si impostano le stesse dimensioni del blocco, l'i/o non verrà allineato correttamente con i blocchi fisici e potrebbe scrivere in due unità diverse in un gruppo RAID, con conseguente latenza.

Nota È importante allineare l'i/o per semplificare le operazioni di lettura/scrittura. Tuttavia, quando l'i/o inizia ad un blocco logico che non si trova all'inizio di un blocco fisico, l'i/o è disallineato. Le operazioni di i/o sono allineate solo quando iniziano presso un blocco logico, il primo blocco logico in un blocco fisico.