pv

转自：https://blog.csdn.net/yinwenjie/article/details/46605451 在上一篇《标准Web系统的架构分层》文章中，我们概述了WEB系统架构中的分层架设体系，介绍了包括负载均衡层、业务层、业务通信层、数据存储层的作用和存在意义。从本片文章开始，我们将首先详细讲解负载均衡层的架构原理和选型场景。 1、不同的负载场景 我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”，那么不同的业务场景需要的负载均衡方式又是不一样的，架构师还要考虑架构方案的成本、可扩展性、运维难易度等问题。下面我们先介绍几种典型的不同业务场景，大家也可以先想一下如果是您，会怎么架设这些场景的负载均衡层。 需要注意的是，这个系统的文章，我们都将使用这几个典型的业务场景来讲解系统架构的设计递归设计。在后续几篇介绍负载层架构的文章中，我们也将通过这几个典型的业务场景讲解负载层的架构方案。 1.1、负载场景一 这是一个国家级物流园区的货运订单和物流管理系统。在物流园区内的货运代理商、合作司机（货运车辆）、园区管理员和客服人员都要使用这套系统。每日RUV在1万人次，日PV在10万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品是否能起到提高效率的作用”。可以看出整个系统基本上没有访问压力

问题 今天机器上有个pv不用了，删除关联pvc后，删除pv时候出现问题，如下，删除mysql-wordpress [root@cbov10-devk8s56-117 mysql]# kubectl get pv|grep mysql mysql-pv-volume 5Gi RWO Retain Bound default/mysql-pv-claim manual 153d mysql-wordpress 5Gi RWX Retain Bound basic-server/mysql-wordpress mysql-wordpress 66m [root@cbov10-devk8s56-117 mysql]# kubectl delete pv mysql-wordpress persistentvolume "mysql-wordpress" deleted ^C [root@cbov10-devk8s56-117 mysql]# kubectl delete pv mysql-wordpress persistentvolume "mysql-wordpress" deleted ^C 　一直删除不掉 解决方案 [root@cbov10-devk8s56-117 mysql]# kubectl patch pv mysql-wordpress -p '{"metadata":{

一、含义 含义 英文 计算 PV 页面访问量 Page View 每打开一次页面PV计数+1，刷新页面也是 UV 独立访客访问数 Unique Visitor 一台电脑终端 为一个访客 IV 独立IP访问数 Initialization Vector 以一个 独立的IP 在一个计算时段内访问网站计算为1次IP访问数 在同一个计算时段内不管这个IP访问多少次均计算为1次。计算时段有以1天为一个计算时段，也有以1个小时为一个计算时段。 二、拓展 1、PV 访问量, 即页面浏览量或点击量，衡量网站用户访问的网页数量；在一定统计周期内用户每打开或刷新一个页面就记录1次，多次打开或刷新同一页面则浏览量累计。 2、UV 独立访客，统计1天内访问某站点的用户数(以cookie为依据);访问网站的一台电脑客户端为一个访客。可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的cookies实现的。如果更换了IP后但不清除cookies，再访问相同网站，该网站的统计中UV数是不变的。如果用户不保存cookies访问、清除了cookies或者更换设备访问，计数会加1。00:00-24:00内相同的客户端多次访问只计为1个访客。 3、IV 独立IP数，是指1天内多少个独立的IP浏览了页面，即统计不同的IP浏览用户数量。同一IP不管访问了几个页面，独立IP数均为1；不同的IP浏览页面

Mysql部署 关于持久化部署mysql数据库 mysql数据库如果简单地部署在k8s集群上，当pods重启时，数据可能会造成丢失，经过查找资料，发现通过PV和PVC可以进行一个持久化的部署。 PV、PVC PersistentVolume（持久卷） 和 PersistentVolumeClaim（持久卷申请） PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。 PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV 1.什么是持久化？ 本人找了好多文章都没有找到满意的答案，最后是从孙卫琴写的《精通Hibernate：Java对象持久化技术详解》中，看到如下的解释，感觉还是比较完整的。摘抄如下： 狭义的理解: “持久化”仅仅指把域对象永久保存到数据库中；广义的理解,“持久化”包括和数据库相关的各种操作。 ● 保存：把域对象永久保存到数据库。 ● 更新：更新数据库中域对象的状态。 ● 删除：从数据库中删除一个域对象。 ● 加载：根据特定的OID

Note: Click her e to download the full example code Message Passing Tutorial Author: Minjie Wang , Quan Gan, Yu Gai, Zheng Zhang 在本教程中，您将学习如何在小图上将不同级别的PageRank消息传递API。 在DGL中，消息传递和特征转换是用户定义的函数（UDFs）。 The PageRank algorithm 在PageRank的每次迭代中，每个节点（网页）首先将其PageRank值均匀地分散到其下游节点。 每个节点的新PageRank值是通过汇总从其邻居收到的PageRank值来计算的，然后通过阻尼因子进行调整： P V ( u ) = 1 − d N + d × ∑ v ∈ N ( u ) P V ( v ) D ( v ) PV(u) = \frac{1-d}{N} + d \times \sum_{v \in \mathcal{N}(u)} \frac{PV(v)}{D(v)} P V ( u ) = N 1 − d ​ + d × v ∈ N ( u ) ∑ ​ D ( v ) P V ( v ) ​ 此处， N N N 表示图中的节点数目， v v v 是节点 u u u 的邻近节点， D ( v ) D(v) D ( v ) 是节点 v

在我们的应用中可能经常有文件存储的需求，在docker的部署中，我们是通过将容器中的目录直接挂载到宿主机的目录上来解决这个问题的，那么k8s部署的方式肯定有所不同，k8s因为是多节点的，每个pod挂载的是对应节点的某个目录，这个会导致节点数据的一致性问题；在k8s中主要通过pvc的方式进行文件的挂载管理； 1.PVC PVC 的全称是：PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明，PVC 消耗的是 PV 资源，用不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。 在使用 PVC 之前，我们还得把其他节点上的 nfs 客户端给安装上，使用命令： yum -y install nfs-utils rpcbind 在使用PVC之前，我们要先创建PV 2.创建PV yml文件如下所示： apiVersion: v1 kind: PersistentVolume metadata: name: powerflow-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteMany storageClassName: powerflow-pv persistentVolumeReclaimPolicy: Recycle nfs: path: /mnt/data/pv server:

LVM简介： 是一种管理磁盘的机制 管理磁盘的两种方式分为基本分区管理，以及LVM方式的管理； 首先看一下LVM的架构图； 基本分区 ( MBR | GPT ) ---- > Filesystem（制作文件系统类型） ---- > mount（挂载） 逻辑卷LVM ---- > Filesystem（制作文件系统类型） ---- > mount（挂载） LVM中含有几个概念 pv: 物理卷，作为真正存储数据的物理磁盘，使用lvm管理磁盘分区的时候需要制作（可以是已经分区好的磁盘设备，也可以是没有分区好的磁盘设备） vg : 卷组，多个pv组成，类似于多个小磁盘组合成一个大型磁盘列阵 lv : 逻辑卷，可制作为文件系统（格式化），进行挂载使用 LE : 逻辑区域是逻辑卷中可用于分配的最小存储单元，逻辑区域的大小取决于逻辑卷所在卷组中的物理区域的大小。 PE ：物理区域是物理卷中可用于分配的最小存储单元，物理区域大小在建立卷组（VG）时指定，一旦确定不能更改，同一卷组所有物理卷的物理区域大小需一致，新的pv加入到vg后，PE的大小自动更改为vg中定义的PE大小; 注意 ：其实LE是放在LV上来看是LE ，而放在PV上来看就是PE了； 创建pv 前提：需要在虚拟机中含有没有使用的磁盘或者磁盘分区 例如：在虚拟机中添加了一块磁盘，已经将其分了两个分区分别为sdc1 sdc2,均为10G大小

1. k8s PV 与 PVC PV 是已经由管理员提供或者动态使用供应的集群中的一块存储的存储类。它是集群中的资源，就像节点是集群资源一样。PV是类似于Volumes的卷插件，但是其生命周期独立于使用PV的任何单个Pod。此API对象捕获NFS，iSCSI或特定于云提供商的存储系统的存储实现的详细信息。 PVC 是由用户进行存储的请求。它类似于豆荚。容器消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以将它们安装为读/写一次或多次只读）。 尽管PVC允许用户使用抽象的存储资源，但是PV对于不同的问题，用户通常需要具有不同的属性（例如性能）。集群管理员需要能够以多种PV方式提供各种不同的功能，而不仅仅是大小和访问模式，而又不让用户了解如何实现这些卷的细节。对于这些需求，有StorageClass 资源，如：ssd、nfs等等。 2. 使用PV与PVC apiVersion: v1 kind: PersistentVolume metadata: name: nexus-data spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy:

Linux LVM学习 先了解一下PV,VG,LV的命令 一张图先看关系 物理存储介质（The physical media） 这里指系统的存储设备：硬盘，如：/dev/hda、/dev/sda等等，是存储系统最低层的存储单元。 物理卷（PV physical volume） 物理卷就是指硬盘分区或从逻辑上与磁盘分区具有同样功能的设备(如RAID)，是LVM的基本存储逻辑块，但和基本的物理存储介质（如分区、磁盘等）比较，却包含有与LVM相关的管理参数。 卷组（VG Volume Group） LVM卷组类似于非LVM系统中的物理硬盘，其由物理卷组成。可以在卷组上创建一个或多个“LVM分区”（逻辑卷），LVM卷组由一个或多个物理卷组成。 逻辑卷（LV logical volume） LVM的逻辑卷类似于非LVM系统中的硬盘分区，在逻辑卷之上可以建立文件系统(比如/home或者/usr等) 物理存储介质》物理卷》卷组》逻辑卷 1，首先查看系统安装时哪些分区使用LV卷 命令： df -h 可以看到是有四个分区 用lsblk命令查看比较清楚，也比较完整，一共5个分区使用了LVM卷管理。命令：lsblk 最后还可以使用vgs命令查看相关卷组信息,PV1个，LV 共有5个.命令：vgs 2，查看物理卷，卷组等信息，命令:PVS 1,PV是第一块硬盘第5个分区/dev/sda5 2,vg的名字

PV和PVC Kubernetes Volume提供了非常好的数据持久化方案，不过对于大型Kubernetes集群来说管理上还有不方便之处。Volume方案需要创建Pod或者Deployment的管理员对共享存储的参数和机制比较清楚，甚至对一些存储的访问是需要身份验证的，这导致集群用户（存储使用者）和系统管理员（存储管理员）的职责耦合在一起了。但对于大型的生产环境，为了管理的效率和安全，集群用户（存储使用者）和系统管理员（存储管理员）是分置的。 Kubernetes引入了两个新的API资源PersistentVolume和PersistentVolumeClaim来解决这个问题。 PersistentVolume（PV）是集群中由系统管理员配置的一段网络存储。它是集群中的资源，就像node是集群资源一样。PV也是像是Volumes一样的存储插件，但其生命周期独立于使用PV的任何单个Pod。PV配置存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。PV属于集群级别资源，不属于任何的Namespace。 PersistentVolumeClaim（PVC）是使用存储的请求，属于Namespace中的资源。PVC类似于Pod，Pod消耗node资源，PVC消耗PV资源。Pod可以请求特定级别的计算资源（CPU和内存），PVC可以请求特定大小和访问模式的存储资源。