Ⅰ docker使用NFS解決數據存儲問題
NFS ：Net File System 網路文件存儲系統
將雲存儲的磁碟掛載到本地計算機，本文所用的NFS提供商是阿里雲網路文件存儲系統。
1. 首先在阿里雲配置好網路文件存儲系統
具體文檔在該鏈接中：https://help.aliyun.com/document_detail/27526.html?spm=a2c4g.11186623.6.559.121b5ddemjaPZP
2. 在本地linux測試掛載
首先安裝nfs客戶端工具
sudo apt-get install nfs-common
掛載，執行下列命令後，即可看到 /mount-point 掛載點出現，有關mount和umount命令的使用，需要自行網路和谷歌
sudo mount -t nfs -o vers=4.0,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport file-system-id-xxxx.region.nas.aliyuncs.com:/ /mount-point
3. 使用docker創建驅動為nfs類型的磁碟(volume,不推薦使用bind mount)
docker volume create --driver local --opt type=nfs --opt o=addr=192.168.138.130,rw --opt device=:/data/nfs volume-nfs
4. 運行容器時，掛載 volume-nfs 磁碟即可
使用-v選項將volume掛載到容器上
docker run -dit --name data1 -v volume-nfs:/mnt ubuntu:16.04
Ⅱ nfs:server is not responding,still trying的解決辦法
系統 ：centos7.9
nfs版本：nfsstat: 1.3.0
rpcbind版本：rpcbind：0.2.0
查看message日誌發現nfs 客戶連接端報如下錯誤
問題原因：
Mandag 27 november 2006 20:12 skrev Verner Kjærsgaard:
NFS協議到現在經歷了V1、V2、V3、V4四個版本，但是它有一個缺點就是協議沒有用戶認證機制，而且數據在網路上傳送的時候是明文傳送，所以安全性極差，一般只能在區域網中使用。
NFSv3是1995年發布的，相比NFSv3，NFSv4發生了比較大的變化，最大的變化是NFSv4有狀態了。NFSv2和NFSv3都是無狀態協議，服務端不需要維護客戶端的狀態信息。無狀態協議的一個優點在於災難恢復，當伺服器出現問題後，客戶端只需要重復發送失敗請求就可以了，直到收到服務端的響應信息。但是某些操作必須需要狀態，如文件鎖。如果客戶端申請了文件鎖，但是服務端重啟了，由於NFSv3無狀態，客戶端再執行鎖操作可能就會出錯了。NFSv3需要NLM協助才能實現文件鎖功能，但是有的時候兩者配合不夠協調。NFSv4設計成了一種有狀態的協議，自身實現了文件鎖功能，就不需要NLM協議了。
後來的 NFSv4.1
與NFSv4.0相比，NFSv4.1最大的變化是支持並行存儲了。在以前的協議中，客戶端直接與伺服器連接，客戶端直接將數據傳輸到伺服器中。當客戶端數量較少時這種方式沒有問題，但是如果大量的客戶端要訪問數據時，NFS伺服器很快就會成為一個瓶頸，抑制了系統的性能。NFSv4.1支持並行存儲，伺服器由一台元數據伺服器(MDS)和多台數據伺服器(DS)構成，元數據伺服器只管理文件在磁碟中的布局，數據傳輸在客戶端和數據伺服器之間直接進行。由於系統中包含多台數據伺服器，因此數據可以以並行方式訪問，系統吞吐量迅速提升。現在新的是nfsv4.2
所以盡可能用nfs4
補充：
nfs4掛載的fsid問題
問題現象：
掛載nfs4時，報錯：reason given by server :No such file or directory
背景知識：
NFSv4將所有共享使用一個虛擬文件系統展示給客戶端。偽文件系統根目錄(/)使用fsid=0標示，只有一個共享可以是fsid=0。客戶端需要使用「nfs server ip:/」掛載偽文件系統，偽文件系統一般使用RO方式共享，其他共享可以通過mount –bind選項在偽文件系統目錄下掛載。客戶端掛載過程需要通過mount –t nfs4指定NFS版本為4，默認採用nfsv3。
解決：
以下是我的配置文件，我想掛在/datapool/nfs目錄
/ *(rw,fsid=0,insecure,no_root_squash)
/datapool/nfs *(rw,fsid=1000,insecure,no_root_squash
然後mount -t nfs4 ip:/datapool/nfs /mnt/nfs/
nfs配置參數選項說明：
ro：共享目錄只讀；
rw：共享目錄可讀可寫；
all_squash：所有訪問用戶都映射為匿名用戶或用戶組；
no_all_squash（默認）：訪問用戶先與本機用戶匹配，匹配失敗後再映射為匿名用戶或用戶組；
root_squash（默認）：將來訪的root用戶映射為匿名用戶或用戶組；
no_root_squash：來訪的root用戶保持root帳號許可權；
anonuid=<UID>：指定匿名訪問用戶的本地用戶UID，默認為nfsnobody（65534）；
anongid=<GID>：指定匿名訪問用戶的本地用戶組GID，默認為nfsnobody（65534）；
secure（默認）：限制客戶端只能從小於1024的tcp/ip埠連接伺服器；
insecure：允許客戶端從大於1024的tcp/ip埠連接伺服器；
sync：將數據同步寫入內存緩沖區與磁碟中，效率低，但可以保證數據的一致性；
async：將數據先保存在內存緩沖區中，必要時才寫入磁碟；
wdelay（默認）：檢查是否有相關的寫操作，如果有則將這些寫操作一起執行，這樣可以提高效率；
no_wdelay：若有寫操作則立即執行，應與sync配合使用；
subtree_check（默認） ：若輸出目錄是一個子目錄，則nfs伺服器將檢查其父目錄的許可權；
no_subtree_check ：即使輸出目錄是一個子目錄，nfs伺服器也不檢查其父目錄的許可權，這樣可以提高效率；
Troubleshooting
1、在上面的操作過程中，如果你不幸遇到下面這個問題的話，可以嘗試更新 Linux kernel 或通過打開 IPv6 來解決這個問題，這是1個 bug：
mount.nfs4: Cannot allocate memory
2、如果遇到如下問題，可能是因為你的 mount -t nfs 使用的是 nfsv3 協議，需要明確指出使用 nfsv4 協議掛載 mount -t nfs4：
mount: mount to NFS server 餄.16.20.1' failed: RPC Error: Program not registered.
如果網路不穩定
NFS默認是用UDP協議，換成TCP協議掛載即可：
mount -t nfs 11.11.165.115:/tmp/test0920 /data -o proto=tcp -o nolock
nfs:server xxx.xxx.xxx.xxx is not responding,still trying的解決方法
方法1 ：
我在 arm 上通過NFS共享文件時出現下面的錯誤提示
nfs:server is not responding,still trying 原因分析： NFS 的默認傳輸協議是 UDP，而PC機與嵌入式系統通過UPD交互時就會出現嚴重的網卡丟包現象。
解決方法：在客戶端改用TCP協議，使用下面的命令， **#mount -o tcp 10.10.19.25:/home/export /mnt/local
方法2：** 在目標板上通過NFS復制PC機上較大文件到目標板上的時候遇到的問題：
nfs: server *** not responding, still trying
修改方法：
nfs mount時候出現的NFS崩潰，按照以下的方式mount
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client
附 問題四：在測試時，「./progressbar -qws」後出現如Q3一樣的提示 ，按Q3來處理。
以上參考了一些 「 快樂的天空」的經驗，他的網頁是：
http://blog.chinaunix.net/u2/67519/showart_677885.html
他的
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /host
應該改成
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client
Ⅲ Kubernetes存儲
在 Docker的設計 實現中， 容器中的數據是臨時性的，當容器銷毀或重新啟動時存儲在容器內部的數據將會全部丟失 ，但實際上很多容器化應用是需要持久化保存的數據，這就需要使用Docker數據卷掛載宿主機上的文件或者目錄到容器中以保證數據的持久化存儲。在 Kubernetes中Pod重建如同Docker銷毀一樣，數據就會丟失 ，Kubernetes也通過掛載數據卷方式為Pod數據提供持久化能力，這些數據卷以Pod為最小單位進行存儲，通過共享存儲或分布式存儲在各個Pod之間實現共享。
Kubernetes是由Master節點及Node節點組成的，在Master節點中通過etcd存儲了Kubernetes集群的節點信息、Pod信息、容器信息、配置信息。Node節點主要對外提供容器服務，著重描述Node節點與存儲相關的內容。
Kubernetes以Pod為單位對外提供容器服務，真正的服務是通過Service進行訪問的。 Kubernetes中的服務按類型分成三種：無狀態服務（stateless）、普通有狀態服務、有狀態集群服務 。
無狀態服務：不需要持久化存儲的，即使Pod重建也不會受影響，只要確保服務的可靠性便可，Kubernetes通過ReplicationSet來保證某個服務的實例數量。
普通有狀態服務：這類服務需要保留服務的狀態，通常通過Kubernetes提供的Volume及Persistent Volume、Persistent Volume Claim來保存狀態。
有狀態的集群服務：這類服務除了保存服務狀態的同時還需要提供集群管理的功能，集群管理過程中也涉及臨時數據的保存、集群內數據共享等。
Kubernetes中涉及存儲的主要使用場景 ：
1) 容器集群相關配置信息及運行時信息保存，這類信息存儲在etcd中。
2) 服務的基本配置文件及證書文件。
3) 服務的狀態存儲、數據存儲信息。
4) 集群內不同服務交換共享的數據信息。
1) 臨時文件形式 ：同一個Pod內不同容器間通過共享內存方式訪問，會創建一個空目錄，交換完信息後會刪除這個空目錄。
2) HostPath方式 ：同一個Node內不同的Pod間進行信息共享使用HostPath方式(比如時區timezone)。如果Pod配置了EmptyDir數據卷，則它在Pod的生命周期內都會存在。當Pod被分配到Node上的時候，會在Node上創建EmptyDir數據卷，並掛載到Pod的容器中。
3) PV及PVC： Kubernetes的持久化存儲機制的核心是PV(Persistent Volume)、PVC (Persistent Volume Claim)。PV是Volume插件，關聯到真正的後端存儲系統，PVC是從PV中申請資源，而不需要關心存儲的提供方。PVC和PV的關系就如同Pod和Node一樣，Pod是消費Node提供的資源，PVC是消費PV提供的存儲資源。PVC和PV通過匹配完成綁定關系，PVC可以被Pod里的容器掛載。
4) 網路方式 ：不同Node節點之間的數據共享通過網路方式使用，通常採用分布式存儲方式。開源的分布式文件系統比較流行的選擇有GlusterFS和Ceph，還有一些其他的分布式文件系統(NFS)選擇。
5) 自定義插件方式 ：Kubernetes提供了豐富的Volume的插件來進行存儲管理。如果存儲管理介面不夠用，用戶可以通過CSI或Flex Volume進行擴展。
存儲管理組件（存儲組件）主要是接收北向API收到的Rest請求，維護持久卷的生命周期管理。如創建、刪除卷， 存儲組件負責與後端存儲軟體交互完成實際的創建、刪除卷等操作；並負責調用Kubernetes原生介面創建對應的PVC和PV 。
存儲後端系統提供數據文件的實際持久化能力，不僅需要實現數據文件的讀寫、副本復制等存儲操作，通常還需具備多節點高可用的能力。
當需要為自己的微服務應用掛載持久卷時，只需要通過存儲組件創建持久卷，存儲組件會在Kubernetes業務集群創建PVC/PV，並到後端存儲系統(如GlusterFS)上創建真正的物理Volume，同時維護好PVC/PV/Volume之間的一一映射對應關系。這樣，用戶部署容器時就可以選擇掛載相應的持久卷，部署後相應的卷就可以掛載到對應的容器。應用掛載持久卷後，進行讀寫時就類似於本地目錄的讀寫操作。
在Pod進行重建或者遷移到其他節點時，Pod可以自動掛回原來對應的持久卷，繼續使用原先的數據。多個Pod可以共享一個持久卷，從而達到容器間文件共享的目的。
摘抄自陸平的《基於Kubernetes的容器雲平台實戰》一書的第11章Kubernetes存儲
Ⅳ iscsi、cifs、nfs在存儲上的區別。
iscsi、cifs、nfs區別為：對象不同、環境不同、方式不同。
一、對象不同
1、iscsi：iscsi是針對數據塊存儲的。
2、cifs：cifs是針對共享文件存儲的。
3、nfs：nfs是針對共享文件存儲的。
二、環境不同
1、iscsi：iscsi主要應用在Windows環境下，適用於TCP／IP通訊協議。
2、cifs：cifs主要應用在NT/Windows環境下。
3、nfs：nfs主要應用在UNIX環境下，廣泛應用在FreeBSD、SCO、Solaris等等異構操作系統平台。
三、方式不同
1、iscsi：iscsi並不能用於在磁碟中存儲和管理數據，是通過TCP/IP網路傳輸文件時的文件組織格式和數據傳輸方式。
2、cifs：cifs讓協議運行於TCP/IP通信協議之上，讓Unix計算機可以在網路鄰居上被Windows計算機看到，並進一步傳遞存儲數據。
3、nfs：nfs能夠支持在不同類型的系統之間通過網路進行文件共享存儲。
Ⅳ NFS與雲存儲有什麼關系
NFS，就是客戶端和伺服器之間的訪問，強調的是共享文件系統。
雲存儲，就是雲計算理念，首先他更龐大，資源更廣，客戶可以按需付費。
共同點不多，雲存儲的概念更廣一點。不知道對不對，請見諒！
Ⅵ 掛載網路存儲NFS的三種方法
NAS是網路文件系統，可以通過三種方法來掛載。
1、mount手動掛載
可以指定更加詳細的參數，-t nfs指定NFS文件系統，-o rw,sync指定讀寫以及立即同步寫操作（默認為非同步）。
2、/etc/fstab開機自動掛載
系統開機時會主動讀取/etc/fstab這個文件中的內容，根據文件裡面的配置掛載磁碟。
3、autofs 自動掛載
自動掛載器是一種服務autofs，可以根據需要自動掛載NFS共享，並且在不使用NFS時自動卸載這些共享。NFS不像/etc/fstab一樣永久連接，可以釋放網路和系統資源。
Autofs與Mount/Umount的不同之處在於，它是一種看守程序。如果它檢測到用戶正試圖訪問一個尚未掛接的文件系統，它就會自動檢測該文件系統，如果存在，那麼Autofs會自動將其掛接。另一方面，如果它檢測到某個已掛接的文件系統在一段時間內（/etc/autofs.conf中指定，默認300s）沒有被使用，那麼Autofs會自動將其卸載。因此一旦運行了Autofs後，用戶就不再需要手動完成文件系統的掛接和卸載。
編輯主映射文件/etc/auto.master，添加/rhome /etc/auto.rhome映射
編輯vim /etc/auto.rhome，添加掛載信息remoteuser1 -rw materials.example.com:/rhome/remoteuser1
因為時autofs服務，需要systemctl enable --now autofs，設置自啟動並立即生效 。