ScaleIO與XtremSW Cache如何整合呢?

標籤：style   blog   http   使用   os   io   strong   資料   

在ScaleIO上, XtremSW Cache主要有兩種部署方式:

• 把XtremSW Cache在每台server的內部用作cache - 在ScaleIO Data Server(SDS)下做cache. 這個和傳統的SAN世界中的VNX Fast cache或VMAX cache的概念差不多.
• 把XtremSW Cache用在應用程式端作cache - 在ScaleIO Data Client(SDC)下做cache. 這個在概念上與資料中心裡的server side caching差不多.

 

Caching inside each server (caching below the SDS)

===============

這麼配置的優勢如下:

• 資料一致性更佳: 對於資料共用要求較高的應用程式來說, 資料一致性至關重要. 如果有一片資料被一台Applicaiton Host改掉了, 與此同時這環境中的另一台host正在修改共用儲存上的相同的這一片資料. 這種情形會導致資料毀壞和各種各樣的不一致. 把XtremCache放在SDS下面, 我們就可以在不冒這種風險的前提下進行加速了, 如此就獲得了一致性.
• 不存在冷緩衝(cold cache): 由於緩衝是在儲存端而不是應用程式端進行的,緩衝是不會被應用程式主機的failover所影響. 所以, 也就不會有冷緩衝需要"預熱"(warm up)的時間了, 所以效能也就更加穩定. 有很多環境中failover是的確會發生的, 不光是由於出錯(failure),(可以被認為是較少發生的情況), 還有主要是為了負載平衡做的failover. 在ScaleIO控制的節點叢集中, 這就很有關係了, 因為scaleIO中的計算資源被賦予計算任務是很有彈性的.
• 緩衝會有更好的利用率: 通過把緩衝部署在每個節點的SDS之下, 我們產生了一個很大的共用的緩衝層, 從而cluster中的所有的應用程式都可以使用cache了. 比如說你有20個節點, 有20個不同的應用程式, 有20塊350GB的XtremCache卡. 你一共有7 TB的flash 緩衝. 有些應用程式緩衝會用的多一些, 有些由於需求少,所以比較少的緩衝就可以滿足它了 - 這都跟應用程式的資料集的大小有關. 通過在每台server中設定緩衝, 你得到了一個7 TB的flash cache可以被動態指派給需要的使用者. 所以, 對於活躍的需要消耗上TB的緩衝的應用程式, 這可以極大地提高緩衝的命中率和整體效能.

 

Application side caching (caching above the SDC)

=================

緩衝僅被部署在某台applicaiton server下, 如此配置的優勢如下:

• 效能: 如果環境對於磁碟延遲非常敏感(零點幾毫秒的提高就能明顯的體現出來), 那麼這種部署方式就比較合適了, 因為資料比較靠近應用, 緩衝並不會消耗網路頻寬.
• 部署考慮: 這種部署的顆粒度更細. 如果僅有某幾個應用需要加速, 那麼部署XtremCache專門加速某幾台虛機就可以了. 而且這裡也沒有前面提到的一致性問題.
• 資料一致: 緩衝卡的軟體必須支援對data corruption的保護, XtremCache是有原生支援的(支援Oracle RAC, 和active / passive clusters 諸如MSCS, VCS 或 native Linux clustering).

 

總之, 要麼Xtrem卡部署在SDS之下, 要麼部署在SDC之上. 部署在SDS之下, ScaleIO是知曉Xtrem卡的存在的; 部署在SDC之上, 那麼這就跟ScaleIO沒啥關係了, 沒有ScaleIO的時候怎麼樣, 還是怎麼樣.

 

資料來源

=================

The Whole is Greater than the Sum

http://www.scaleio.com/blog/entry/the-whole-is-greater-than-the-sum