緩存伺服器部署

㈠ Redis分布式緩存搭建

花了兩天時間整理了之前記錄的Redis單體與哨兵模式的搭建與使用，又補齊了集群模式的使用和搭建經驗，並對集群的一些個原理做了理解。

筆者安裝中遇到的一些問題：

如果make報錯，可能是沒裝gcc或者gcc++編輯器，安裝之 yum -y install gcc gcc-c++ kernel-devel ，有可能還是提示一些個c文件編譯不過，gcc -v查看下版本，如果不到5.3那麼升級一下gcc：

在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable

scl enable devtoolset-9 bash

重新make clean, make

這回編譯通過了，提示讓你最好make test一下/

執行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test

那就升級tcl， yum install tcl

重新make test，如果還有error就刪了目錄，重新tar包解壓重新make , make test

o/ All tests passed without errors! ，表示編譯成功。

然後make install即可。

直接運行命令： ./redis-server /usr/redis-6.0.3/redis.conf &

redis.conf 配置文件里 bind 0.0.0.0 設置外部訪問， requirepass xxxx 設置密碼。

redis高可用方案有兩種：

常用搭建方案為1主1從或1主2從+3哨兵監控主節點， 以及3主3從6節點集群。

（1）sentinel哨兵

/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &

sentinel2.conf配置：

坑1：master節點也會在故障轉移後成為從節點，也需要配置masterauth

當kill master進程之後，經過sentinel選舉，slave成為了新的master，再次啟動原master，提示如下錯誤：

原因是此時的master再次啟動已經是slave了，需要向現在的新master輸入密碼，所以需要在master.conf
中配置：

坑2：哨兵配置文件要暴露客戶端可以訪問到的master地址

在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置該哨兵對應的master名字、master地址和埠，以及達到多少個哨兵選舉通過認為master掛掉。其中master地址要站在redis訪問者（也就是客戶端）的角度、配置訪問者能訪問的地址，例如sentinel與master在一台伺服器（122.xx.xxx.xxx）上，那麼相對sentinel其master在本機也就是127.0.0.1上，這樣 sentinel monitor mymaster 127.0.0.1 6379 2 邏輯上沒有問題，但是如果另外伺服器上的springboot通過lettuce訪問這個redis哨兵，則得到的master地址為127.0.0.1，也就是springboot所在伺服器本機，這顯然就有問題了。

附springboot2.1 redis哨兵配置：

坑3：要注意配置文件.conf會被哨兵修改

redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。

曾經遇到過這樣一個問題，大致的信息如下

slaves莫名其妙多了一個，master的地址也明明改了真實對外的地址，這里又變成127.0.0.1 !
最後，把5個redis進程都停掉，逐個檢查配置文件，發現redis的配置文件在主從哨兵模式會被修改，master的配置文件最後邊莫名其妙多了一行replicaof 127.0.0.1 7001， 懷疑應該是之前配置錯誤的時候（見坑2）被哨兵動態加上去的！ 總之，實踐中一定要多注意配置文件的變化。

（2）集群

當數據量大到一定程度，比如幾十上百G，哨兵模式不夠用了需要做水平拆分，早些年是使用codis，twemproxy這些第三方中間件來做分片的，即 客戶端 -> 中間件 -> Redis server 這樣的模式，中間件使用一致性Hash演算法來確定key在哪個分片上。後來Redis官方提供了方案，大家就都採用官方的Redis Cluster方案了。

Redis Cluster從邏輯上分16384個hash slot，分片演算法是 CRC16(key) mod 16384 得到key應該對應哪個slot，據此判斷這個slot屬於哪個節點。

每個節點可以設置1或多個從節點，常用的是3主節點3從節點的方案。

reshard，重新分片，可以指定從哪幾個節點移動一些hash槽到另一個節點去。重新分片的過程對客戶端透明，不影響線上業務。

搭建Redis cluster

redis.conf文件關鍵的幾個配置：

啟動6個集群節點

[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]

這時候這6個節點還是獨立的，要把他們配置成集群：

說明： -a xxxx 是因為筆者在redis.conf中配置了requirepass xxxx密碼，然後 --cluster-replicas 1 中的1表示每個master節點有1個從節點。

上述命令執行完以後會有一個詢問： Can I set the above configuration? yes同意自動做好的分片即可。

最後 All 16384 slots covered. 表示集群中16384個slot中的每一個都有至少有1個master節點在處理，集群啟動成功。

查看集群狀態：

坑1：暴露給客戶端的節點地址不對

使用lettuce連接發現連不上，查看日誌 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里邊配置master地址犯的錯誤一樣，集群啟動的時候帶的地址應該是提供給客戶端訪問的地址。

我們要重建集群：先把6個redis進程停掉，然後刪除 nodes-7001.conf 這些節點配置文件，刪除持久化文件 mp.rdb 、 appendonly.aof ，重新啟動6個進程，在重新建立集群：

然後，還是連不上，這次報錯 connection timed out: /172.xx.0.xx:7004 ，發現連到企鵝雲伺服器的內網地址上了！

解決辦法，修改每個節點的redis.conf配置文件，找到如下說明：

所以增加配置：

然後再重新構建集群，停進程、改配置、刪除節點文件和持久化文件、啟動進程、配置集群。。。再來一套（累死了）

重新使用Lettuce測試，這次終於連上了！

坑2：Lettuce客戶端在master節點故障時沒有自動切換到從節點

name這個key在7002上，kill這個進程模擬master下線，然後Lettuce一直重連。我們期望的是應該能自動切換到其slave 7006上去，如下圖：

重新啟動7002進程，

7006已成為新master，7002成為它的slave，然後Lettuce也能連接上了。
解決辦法，修改Lettuce的配置：

筆者用的是springboot 2.1 spring-boot-starter-data-redis 默認的Lettuce客戶端，當使用Redis cluster集群模式時，需要配置一下 RedisConnectionFactory 開啟自適應刷新來做故障轉移時的自動切換從節點進行連接。

重新測試：停掉master 7006，這次Lettuce可以正常切換連到7002slave上去了。（仍然會不斷的在日誌里報連接錯誤，因為需要一直嘗試重連7006，但因為有7002從節點頂上了、所以應用是可以正常使用的）

Redis不保證數據的強一致性

Redis並不保證數據的強一致性，也就是取CAP定理中的AP

關於一致性Hash演算法，可以參考 一致性Hash演算法 - (jianshu.com)

Redis cluster使用的是hash slot演算法，跟一致性Hash演算法不太一樣，固定16384個hash槽，然後計算key落在哪個slot里邊（計算key的CRC16值再對16384取模），key找的是slot而不是節點，而slot與節點的對應關系可以通過reshard改變並通過gossip協議擴散到集群中的每一個節點、進而可以為客戶端獲知，這樣key的節點定址就跟具體的節點個數沒關系了。也同樣解決了普通hash取模演算法當節點個數發生變化時，大量key對應的定址都發生改動導致緩存失效的問題。

比如集群增加了1個節點，這時候如果不做任何操作，那麼新增加的這個節點上是沒有slot的，所有slot都在原來的節點上且對應關系不變、所以沒有因為節點個數變動而緩存失效，當reshard一部分slot到新節點後，客戶端獲取到新遷移的這部分slot與新節點的對應關系、定址到新節點，而沒遷移的slot仍然定址到原來的節點。

關於熱遷移，猜想，內部應該是先做復制遷移，等遷移完了，再切換slot與節點的對應關系，復制沒有完成之前仍按照原來的slot與節點對應關系去原節點訪問。復制結束之後，再刪除原節點上已經遷移的slot所對應的key。

與哨兵模式比較類似，當1個節點發現某個master節點故障了、會對這個故障節點進行pfail主觀宕機，然後會通過gossip協議通知到集群中的其他節點、其他節點也執行判斷pfail並gossip擴散廣播這一過程，當超過半數節點pfail時那麼故障節點就是fail客觀宕機。接下來所有的master節點會在故障節點的從節點中選出一個新的主節點，此時所有的master節點中超過半數的都投票選舉了故障節點的某個從節點，那麼這個從節點當選新的master節點。

所有節點都持有元數據，節點之間通過gossip這種二進制協議進行通信、發送自己的元數據信息給其他節點、故障檢測、集群配置更新、故障轉移授權等等。

這種去中心化的分布式節點之間內部協調，包括故障識別、故障轉移、選主等等，核心在於gossip擴散協議，能夠支撐這樣的廣播協議在於所有的節點都持有一份完整的集群元數據，即所有的節點都知悉當前集群全局的情況。

Redis高可用方案 - (jianshu.com)

面試題:Redis 集群模式的工作原理能說一下么 - 雲+社區 - 騰訊雲 (tencent.com)

深度圖解Redis Cluster原理 - detectiveHLH - 博客園 (cnblogs.com)

Redis學習筆記之集群重啟和遇到的坑-阿里雲開發者社區 (aliyun.com)

雲伺服器Redis集群部署及客戶端通過公網IP連接問題

㈡ 緩存-redis 三種模式搭建和運行原理

標簽： redis 緩存 主從 哨兵 集群

本文簡單的介紹redis三種模式在linux的安裝部署和數據存儲的總結，希望可以相互交流相互提升。

對於Centos7在安裝redis之前需要進行一些常用工具的安裝：

關閉防火牆

正式安裝redis

在redis進行maketest時候會出現一系列的異常，有如下解決方案：

用redis-server啟動一下redis，做一些實驗沒什麼意義。

要把redis作為一個系統的daemon進程去運行的，每次系統啟動，redis進程一起啟動，操作不走如下：

RDB和AOF是redis的一種數據持久化的機制。 持久化 是為了避免系統在發生災難性的系統故障時導致的系統數據丟失。我們一般會將數據存放在本地磁碟，還會定期的將數據上傳到雲伺服器。
RDB 是redis的snapshotting，通過redis.conf中的save配置進行設置，如 save 60 1000:

AOF 是以appendonly方式進行數據的儲存的，開啟AOF模式後，所有存進redis內存的數據都會進入os cache中,然後默認1秒執行一次fsync寫入追加到appendonly.aof文件中。一般我們配置redis.conf中的一下指令：

AOF和RDB模式我們一般在生產環境都會打開，一般而言，redis服務掛掉後進行重啟會優先家在aof中的文件。

當啟動一個slave node的時候，它會發送一個PSYNC命令給master node,如果這是slave node重新連接master node，那麼master node僅僅會復制給slave部分缺少的數據;否則如果是slave node第一次連接master node，那麼會觸發一次full resynchronization;
開始full resynchronization的時候，master會啟動一個後台線程，開始生成一份RDB快照文件，同時還會將從客戶端收到的所有寫命令緩存在內存中。RDB文件生成完畢之後，master會將這個RDB發送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到內存中。然後master會將內存中緩存的寫命令發送給slave，slave也會同步這些數據。
slave node如果跟master node有網路故障，斷開了連接，會自動重連。master如果發現有多個slave node都來重新連接，僅僅會啟動一個rdb save操作，用一份數據服務所有slave node。

從redis 2.8開始，就支持主從復制的斷點續傳，如果主從復制過程中，網路連接斷掉了，那麼可以接著上次復制的地方，繼續復制下去，而不是從頭開始復制一份。

master node會在內存中常見一個backlog，master和slave都會保存一個replica offset還有一個master id，offset就是保存在backlog中的。如果master和slave網路連接斷掉了，slave會讓master從上次的replica offset開始繼續復制,但是如果沒有找到對應的offset，那麼就會執行一次resynchronization。

master在內存中直接創建rdb，然後發送給slave，不會在自己本地落地磁碟了，可以有如下配置：

slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令發送給slave。

在redis.conf配置文件中，上面的參數代表至少需要3個slaves節點與master節點進行連接，並且master和每個slave的數據同步延遲不能超過10秒。一旦上面的設定沒有匹配上，則master不在提供相應的服務。

sdown達成的條件很簡單，如果一個哨兵ping一個master，超過了 is-master-down-after-milliseconds 指定的毫秒數之後，就主觀認為master宕機
sdown到odown轉換的條件很簡單，如果一個哨兵在指定時間內，收到了 quorum 指定數量的其他哨兵也認為那個master是sdown了，那麼就認為是odown了，客觀認為master宕機

如果一個slave跟master斷開連接已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那麼slave就被認為不適合選舉為master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

每次一個哨兵要做主備切換，首先需要quorum數量的哨兵認為odown，然後選舉出一個slave來做切換，這個slave還得得到majority哨兵的授權，才能正式執行切換；

（2）SENTINEL RESET *，在所有sentinal上執行，清理所有的master狀態
（3）SENTINEL MASTER mastername，在所有sentinal上執行，查看所有sentinal對數量是否達成了一致

4.3.2 slave的永久下線

讓master摘除某個已經下線的slave：SENTINEL RESET mastername，在所有的哨兵上面執行.

redis的集群模式為了解決系統的橫向擴展以及海量數據的存儲問題，如果你的數據量很大，那麼就可以用redis cluster。
redis cluster可以支撐N個redis master,一個master上面可以掛載多個slave，一般情況我門掛載一個到兩個slave，master在掛掉以後會主動切換到slave上面，或者當一個master上面的slave都掛掉後，集群會從其他master上面找到冗餘的slave掛載到這個master上面，達到了系統的高可用性。

2.1 redis cluster的重要配置

2.2 在三台機器上啟動6個redis實例

將上面的配置文件，在/etc/redis下放6個，分別為: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf

每個啟動腳本內，都修改對應的埠號

2.3 創建集群

解決辦法是 先安裝rvm，再把ruby版本提升至2.3.3

使用redis-trib.rb命令創建集群

--replicas: 表示每個master有幾個slave

redis-trib.rb check 192.168.31.187:7001 查看狀體

3.1 加入新master

以上相同配置完成後，設置啟動腳本進行啟動；然後用如下命令進行node節點添加：

3.2 reshard一些數據過去

3.3 添加node作為slave

3.4 刪除node

㈢ 你了解CDN嗎CDN工作原理幫你了解它

網站卡頓，訪問量大?站長對於CDN加速肯定已經不陌生了，目前CDN加速的使用率也是越來越高，那麼大家在使用CDN加速的同時知道CDN加速的工作原理到底是什麼嗎?CDN加速究竟是怎麼應用於你的網站的呢?

首先來了解一下什麼是 CDN?



CDN的全稱是(Content Delivery Network)，即內容分發網路。其目的是通過在現有的Internet中增加一層新的CACHE(緩存)層，將網站的內容發布到最接近用戶的網路」邊緣「的節點，使用戶可以就近取得所需的內容，提高用戶訪問網站的響應速度。從技術上全面解決由於網路帶寬小、用戶訪問量大、網點分布不均等原因，提高用戶訪問網站的響應速度。

簡單的說，CDN的工作原理就是將您源站的資源緩存到位於全球各地的CDN節點上，用戶請求資源時，就近返回節點上緩存的資源，而不需要每個用戶的請求都回您的源站獲取，避免網路擁塞、緩解源站壓力，保證用戶訪問資源的速度和體驗.

使用了CDN緩存後的網站的訪問過程

1.用戶輸入訪問的域名,操作系統向 LocalDns 查詢域名的ip地址.

2.LocalDns向 ROOT DNS 查詢域名的授權伺服器(這里假設LocalDns緩存過期)

3.ROOT DNS將域名授權dns記錄回應給 LocalDns

4.LocalDns得到域名的授權dns記錄後,繼續向域名授權dns查詢域名的ip地址

5.域名授權dns 查詢域名記錄後(一般是CNAME)，回應給 LocalDns

6.LocalDns 得到域名記錄後,向智能調度DNS查詢域名的ip地址

7.智能調度DNS 根據一定的演算法和策略(比如靜態拓撲，容量等),將最適合的CDN節點ip地址回應給 LocalDns

8.LocalDns 將得到的域名ip地址，回應給 用戶端

9.用戶得到域名ip地址後，訪問站點伺服器

10.CDN節點伺服器應答請求，將內容返回給客戶端.(緩存伺服器一方面在本地進行保存，以備以後使用，二方面把獲取的數據返回給客戶端，完成數據服務過程)

為了實現對普通用戶透明(使用緩存後用戶客戶端無需進行任何設置)訪問，需要使用DNS(域名解析)來引導用戶來訪問Cache伺服器，以實現透明的加速服務。由於用戶訪問網站的第一步就是域名解析,所以通過修改dns來引導用戶訪問是最簡單有效的方式。

騰正 科技 15CDN通過多地域分布式部署，全面智能的監控系統及多盾聯動混合節點防禦技術，毫秒級的防禦響應時間，高效徹底解決CC攻擊帶來的安全和響應速度問題。現在騰正 科技 為了助力大家暢享新年，推出CDN春節特惠活動，20TB流量，10個域名，可使用三個月，價格僅售￥999。

活動詳情

CDN暢享新年活動來襲

20TB流量僅￥999 助力更「快」樂!

流量總數：20TB

域名個數：10個

使用時間：3個月

適用場景：適用於門戶網站、有官網的電商網站、中小型圖片站客戶。

活動時間：2020年1月8日-2020年1月31日

㈣ 存根DNS伺服器作用是什麼，是緩存DNS伺服器嗎其工作原理的又是如何。

管理存根區域的DNS伺服器稱為存根DNS伺服器。一般情況下，不需要單獨部署存根DNS伺服器，而是和其他DNS伺服器類型合用。在存根DNS伺服器和主伺服器之間同樣存在著區域復制

緩存DNS伺服器
緩存DNS伺服器即沒有管理任何區域的DNS伺服器，也不會產生區域復制，它只能緩存DNS名字並且使用緩存的信息來答復DNS客戶端的解析請求。當剛安裝好DNS伺服器時，它就是一個緩存DNS伺服器。緩存DNS伺服器可以通過緩存減少DNS客戶端訪問外部DNS伺服器的網路流量，並且可以降低DNS客戶端解析域名的時間，因此在網路的廣泛的使用。例如一個常見的中小型企業網路接入到Internet的環境，並沒有在內部網路中使用域名，所以沒有架設DNS伺服器，客戶通過配置使用ISP的DNS伺服器來解析Internet域名。此時就可以部署一台緩存DNS伺服器，配置將所有其他DNS域轉發到ISP的DNS伺服器，然後配置客戶使用此緩存DNS伺服器，從而減少解析客戶端請求所需要的時間和客戶訪問外部DNS服務的網路流量

㈤ 如何部署伺服器級別的存儲虛擬化

主機級別的方案中通常只是虛擬化直連主機的存儲，當然也有一些可以部署在一個SAN環境中的多台存儲子系統上。
早先的存儲虛擬化產品常用於簡化內部磁碟驅動器和伺服器外部直連存儲的空間分配，以及支持應用集群。Veritas Volume Manager和Foundation Suite就是首批這類解決方案，這類方案使得存儲擴展，以及為應用程序和文件伺服器提供空間更為簡單快速。
隨著存儲需求的增長遠遠超過直連存儲所能提供的范圍，存儲虛擬化逐漸成為存儲陣列中的一種容量提供方式。而容量持續增長以及諸如iSCSI等小型IT組織負擔得起的共享存儲技術的出現又使得存儲虛擬化技術也融合進基於網路的設備和運行在通用硬體的軟體里。
不過現今的伺服器和桌面虛擬化技術興起給存儲虛擬化技術帶來了新的生機，而基於主機的存儲虛擬化技術正在逐漸回歸。伺服器虛擬化平台必需要基於共享存儲體系架構來實現一些關鍵特性，比如VMware的vMotion和Distributed Resource Schele (DRS)。通過傳統的SAN架構自然可以實現這種共享存儲體系架構，不過越來越多的IT組織開始尋求更簡單的方式來實現共享存儲。基於主機的虛擬化技術就是方式之一。
諸如VMware之類的伺服器虛擬化供應商認為存儲是妨礙虛擬化技術大規模普及的瓶頸之一。這些Hypervisor供應商已經實現了處理器和內存資源的抽象，實現更好的控制並提高資源利用率，他們自然而然也會希望這樣控制存儲。不過將存儲控制功能整合到主機伺服器端，稱之為「存儲Hypervisor」時會帶來一些潛在的問題。處理一些在虛擬伺服器和虛擬桌面環境中至關重要的存儲服務，諸如快照、克隆和自動精簡配置時，會嚴重影響主機伺服器的性能。
Virsto的解決方案
Virsto開發出了一款軟體解決方案，安裝在每台主機伺服器上(無論是一台虛擬機或Hypervisor上的過濾驅動器)並在主存儲上創建一個虛擬化層，稱為Virsto存儲池。其同時創建一個高性能磁碟或者固態存儲區域，成為「vLog」。讀操作會直接指向主存儲，不過寫操作會通過vLog進行，這會給請求的虛擬機或應用程序發回一個確認。然後vLog將這些寫操作非同步地分布寫入主存儲，從而減少對寫性能的影響。該存儲池可以容納多至4層的存儲方式，包括固態存儲和各類型的磁碟驅動器。
和緩存的工作方式類似，vLog通過在存儲前端降低耦合度改善了存儲性能，降低了後端存儲的延遲。其同時將前端主機的隨機寫操作變為順序方式，實現後端存儲的最佳性能。基於Virsto主機的存儲虛擬化軟體實現了以上這些功能。
虛擬存儲設備
基於主機的存儲虛擬化的另一項應用實例是虛擬存儲設備(VSA)
VSA是運行在虛擬機上的存儲控制器，其虛擬化統一集群中的主機所直接連接的存儲。VSA提供一個主機使用的簡易的存儲共享體系架構，並支持高可用性、虛擬機遷移，並改善存儲提供方式。對於很多企業，這種方式可以替代原本需要建立並管理傳統SAN或NAS來支持虛擬伺服器和桌面的體系架構。
vSphere Storage Appliance。VMware的vSphere Storage Appliance以一個虛擬機的方式運行，從在2個或3個節點集群中，每個ESX/ESXi主機所直連的DAS存儲中，創建一個共享存儲池。VMware VSA提供每個節點的RAID保護，並在同一集群的各個節點之間提供鏡像保護。雖然從技術角度上看，VMware VSA是一個基於文件的體系架構，不過其亦為集群中每台主機提供數據塊級別的存儲虛擬化，並用戶可以從這種部署方式中獲取和基於數據塊的共享存儲一樣的收益。
HP的LeftHand Virtual SAN Appliance。雖然和VMware VSA的功能類似，P4000 VSA軟體可以支持每台主機直連DAS以外的方式。其還允許使用iSCSI或FC SAN等外部存儲來創建共享存儲池。這就意味著可以將如何可用的存儲，本地存儲或用於容災的異地存儲，轉變為LeftHand存儲節點。P4000t提供快照和自動精簡配置，並且支持Hyper-V和VMware。
DataCore的SANsymphony-V。DataCore的解決方案是通過在一個虛擬機中部署其SANsymphony軟體來整合其它各個VMware，Hyper-V或XEN主機的直連存儲，形成共享存儲池。SANsymphony-V可以和HP的解決方案那樣虛擬化外部的網路存儲，並且該軟體可以在遷移到傳統的共享存儲體系架構時部署在外部伺服器上。SANsymphony-V同時提供各類存儲服務，譬如快照、自動精簡配置、自動化分層和遠程復制。
FalconStor的NSS Virtual Appliance。FalconStor的Network Storage Server Virtual Appliance(NSSVA)是該公司NASS硬體產品中唯一支持的VMware版本，用網路上其它主機的直連存儲創建一個虛擬存儲池。和DataCore和LeftHand的解決方案類似，該存儲池可以擴展到網路上任何可用的iSCSI存儲上。該NSS Virtual Appliance包括快照、自動精簡配置、讀/寫緩存、遠程復制和卷分層等存儲功能。
基於主機的存儲虛擬化解決方案是目前大多使用在虛擬化伺服器和虛擬化桌面環境中，用以實現環境的高可用性特性，以及改善存儲性能、利用率和管理效率。

㈥ 秒開緩存伺服器4.0版本有幾種部署方式

一共三種

1〉旁路(DNS)網路結構如下：