Ⅰ 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，设置自启动并立即生效 。