對現代企業能否維持的競爭優勢，應用程式的效能扮演關鍵角色。為了能立即存取，即時處理、分析與剖析資料，企業客戶會主動於儲存設備基礎架構加入快閃記憶體。 因應客戶的需求及市場需求急遽成長，許多CIO發現快閃記憶體非常適用於效能密集型的應用，包括資料庫、資料倉儲和大數據分析等。雖然全快閃式與混合式快閃儲存陣列的發展被廣泛討論，但伺服器端的快閃儲存 PCIe 發展得更為快速。Gartner Group 預測 2015 年將有超過 100 萬套出廠。 隨著 PCIe 的價格趨近於 $1/GB，Gartner 也預期 2018 年存在於資料中心的 SSD 設備將高達 50% 為 PCIe。 PCIe最初主要是由橫向擴展架構與 NoSQL 資料庫等超大規模 (HyperScale) 的客戶採用，而PCIe 快閃設備的性價比優勢已成為最近主流，加上全新的軟體定義儲存功能，過去需要採用外部的高延遲高成本的 SAN 型方法其企業使用案例，現在將得以實現。 快取成為獲利的關鍵 PCIe 快取儲存其主要運用在SAN 前端的快取組態內，對於現有的 SAN 而言，使延遲度從幾十毫秒降低到微秒，現有的基礎架構也能增加至數千 IOPs。這類的應用多受 Microsoft® SQL Server 等資料庫採用。資料庫購買單個 PCIe 裝置與快取軟體的價格將可能低於 $10,000，相較於先前即使花費五倍價格也無法大幅改善 SAN 的效能並達到同樣的低延遲特性。，延遲度代表等待時間更長，也就是使用者的反應時間或每秒更少的資料處理次數。在同時考量時間及金錢的成本的前提下下， PCIe 快閃儲存搭配快取軟體將是一個簡單又迅速的解決方法。 共享快閃存取 多數企業的資料庫都需要共享的儲存器。其中， Oracle® 資料庫及 Oracle真正應用集群(RAC) 就是個好例子。RAC 使用 Oracle 的自動儲存管理 (ASM) 功能作為資料庫的卷管理器。ASM 使用磁碟群組來儲存資料檔案，即可實現靈活的伺服器型鏡射選項。現在， Oracle ASM使用快閃記憶體的方式是在 SAN 陣列之內。延遲度和成本問題也使得 SAN 的 Oracle 資料庫所費不貲，隨著環境成長，工作負載的剩餘空間所需的 IOPs 也隨之增加。 HGST 提供的軟體定義儲存，可使 PCIe 快閃作為 ASM 磁碟群組，直接在資料庫伺服器內進行存取及管理。ASM 能依據資料庫集合所需數量的 PCIe 快閃記憶體。由於儲存設備位在伺服器匯流排上，可利用快閃記憶體層讓伺服器達到僅有微秒的延遲度 (Oracle 的 Calibrate_IO 工具無法測量到)。ASM 能偵測到所有的儲存裝置，也可將資料轉移到 SAN 上的儲存設備，達到最佳的性價比。共享快閃記憶體存取額外的好處可改善伺服器核心的運用，並降低 Oracle 的授權費用或是延長現有授權的使用時間。 叢集與伺服器整合 對於MySQL 的資料庫而言，傳統的伺服器配置為主從配對。主伺服器為大型叢集的一部份，叢集中的資料庫行列會由多個主伺服器橫向「共享」擴展。從屬伺服器則是用於分載讀取流量，並在主伺服器發生故障或資料毀損時作為故障轉移的節點使用。 PCIe 快閃記憶體的高速度、低延遲，讓單一裝置即可應付主伺服器的讀寫流量。資料庫和伺服器鮮少發生故障，許多屬站通常只是閒置一旁，浪費電、佔空間還需要冷卻散熱。這些伺服器資源耗用過多 (server sprawl) 的狀況，可透過 PCIe 快閃裝置與伺服器端的快閃叢集軟體輕鬆解決。 叢集軟體能夠讓多個主伺服器下所有快閃記憶體資源集合至單個集用場內，再自集用場為各個主伺服器分配容量。配備少量開放原始碼軟體的從屬伺服器或「多功能伺服器」會作為「收聽器」。當主伺服器故障時，多功能伺服器可裝載並繼續運作，不會有停機的問題，此外，由於所有的主伺服器都會同步複製到集用場內，因此故障發生時不會造成資料損失的情況。由於 MySQL 的複製並非同步處理，可能會有部分交易漏失，因此格外重要。這項簡單但巧妙的變動，對 MySQL 的實體配置所產生的效果可使伺服器數量依據叢集的規模而減少 38% 到 70%。 展望未來 在企業資料庫，延遲度代表等待時間更長，也代表著使用者的反應時間更長或者每秒更少的交易次數。時間及金錢成本雙重考量下，快閃記憶體成為越來越誘人的選項。這代表效率、效能和擴充能力的標準將受到嚴格的檢視。致力於邁向成功的企業必須從自有的資料中獲取更多的利益與價值。 硬體和軟體解決方案必須能夠協助 CIO在效能、複雜度與成本之間找到平衡。這代表未來將會著重於使用全 SSD 環境來加速高峰應用程式，並且透過分層或快取來使用混合式 HDD 與快閃環境以改善延遲情況。 |
首頁|手機版|Chip123 科技應用創新平台 |新契機國際商機整合股份有限公司
GMT+8, 2024-4-16 11:06 PM , Processed in 0.071004 second(s), 16 queries .
Powered by Discuz! X3.2
© 2001-2013 Comsenz Inc.
