Skip to main content
Enterprise applications
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

SAN

貢獻者

有兩個選項可以使用常見的雙磁碟區模型、來設定 MySQL 與 SAN 。

只要 I/O 和容量需求在單一 LUN 檔案系統的限制範圍內、就可以將較小的資料庫放在一對標準 LUN 上。例如、需要大約 2K 隨機 IOPS 的資料庫、可以裝載在單一 LUN 上的單一檔案系統上。同樣地、只有 100GB 大小的資料庫也能放在單一 LUN 上、而不會造成管理問題。

大型資料庫需要多個 LUN 。例如、需要 10 萬 IOPS 的資料庫最可能需要至少八個 LUN 。由於磁碟機的 SCSI 通道數量不足、單一 LUN 將成為瓶頸。10TB 資料庫同樣難以在單一 10TB LUN 上進行管理。邏輯磁碟區管理程式的設計旨在將多個 LUN 的效能和容量功能結合在一起、以改善效能和管理能力。

在這兩種情況下、一對 ONTAP 磁碟區應該足夠。透過簡單的組態、資料檔案 LUN 會與記錄 LUN 一樣置於專用磁碟區中。在邏輯 Volume Manager 組態下、資料檔案 Volume 群組中的所有 LUN 都將位於專用磁碟區、而記錄 Volume 群組的 LUN 則位於第二個專用磁碟區。

提示
  • NetApp 建議 * 在 SAN 上使用兩個檔案系統進行 MySQL 部署:

  • 第一個檔案系統會儲存所有 MySQL 資料、包括資料表空間、資料和索引。

  • 第二個檔案系統會儲存所有記錄(二進位記錄、慢速記錄和交易記錄)。

以這種方式分隔資料有多種原因、包括:

  • 資料檔案和記錄檔的 I/O 模式各不相同。將它們區隔、就能透過 QoS 控制提供更多選項。

  • 最佳化使用 Snapshot 技術需要能夠個別還原資料檔案。將資料檔案與記錄檔混合會干擾資料檔案還原。

  • NetApp SnapMirror 技術可用於為資料庫提供簡單、低 RPO 的災難恢復功能、但是資料檔案和記錄檔需要不同的複寫排程。

註 使用這種基本的兩個磁碟區配置、以符合未來需求的解決方案、以便在需要時使用所有 ONTAP 功能。
提示
  • NetApp 建議 * 使用 ext4 檔案系統格式化磁碟機、因為有下列功能:

  • 延伸的區塊管理方法、用於日誌檔案系統( JFS )中的區塊管理功能、以及延伸檔案系統( XFS )的延遲分配功能。

  • ext4 允許檔案系統最多 1 個 exbibyte ( 2^60 位元組)、檔案最多 16 個 tebibytes ( 16 * 2^40 位元組)。相反地、 ext3 檔案系統僅支援 16TB 的最大檔案系統大小、最大檔案大小為 2TB 。

  • 在 ext4 檔案系統中、多區塊分配( mballoc )會在單一作業中為檔案分配多個區塊、而非如 ext3 中逐一分配。此組態可減少多次呼叫區塊分配器的成本、並最佳化記憶體配置。

  • 雖然 XFS 是許多 Linux 套裝作業系統的預設值、但它以不同方式管理中繼資料、不適合某些 MySQL 組態。

提示
  • NetApp 建議 * 將 4K 區塊大小選項與 mkfs 公用程式搭配使用、以符合現有區塊 LUN 大小。

mkfs.ext4 -b 4096

NetApp LUN 以 4KB 實體區塊儲存資料、產生八個 512 位元組的邏輯區塊。

如果您未設定相同的區塊大小、 I/O 將無法正確對齊實體區塊、而且可能會在 RAID 群組中的兩個不同磁碟機中寫入、導致延遲。

註 請務必調整 I/O 、以順利進行讀寫作業。但是、當 I/O 從不在實體區塊開頭的邏輯區塊開始時、 I/O 會未對齊。I/O 作業只有在邏輯區塊(實體區塊中的第一個邏輯區塊)開始時才會對齊。