XFS

分布式理论（一） CAP 理论 一． CAP 理论前言 CAP 原则又称为 CAP 理论，主要思想是在任何一个分布式系统中都无法同时满足 CAP 。 C （ Consistency ）：表示一致性，所有的节点同一时间看到的是相同的数据。 A （ Avaliablity ）：表示可用性，不管是否成功，确保一个请求都能接收到响应。 P （ Partion Tolerance ）：分区容错性，系统任意分区后，在网络故障时，仍能操作。 如上所述，正如 Gilbert 认为， 一致性 其实就是关系型数据库所讲的 ACID ，一个用户请求要么是成功，要么是失败的，不能有处于一个中间状态；一旦一个事务完成，将来所有事务都必须基于这个完成后的状态；未完成的事务不会互相影响；一旦一个事务完成，就是持戒的。 可用性 其实就是对于一个系统而言，所有的请求都应该 “成功”并且收到“响应”。 分区容错性 其实就是指分布式系统的容错性，一个节点出现了故障，不影响整个集群的正常使用。 二． CAP 理论介绍 如图，在一个网络中， N1 和 N2 即分布式系统中的两个节点，他们都共享数据块 V ，其中有一个值是为 V0 。 l 在满足一致性的时候， A 中的 V0 应该和 B 中的 V0 保持一致的，即 V0=V0 l 在满足可用性的时候，无论请求访问 A 或者是 B 都应该得到响应。 l 在满足分区可用性的时候

在单机的数据库系统之中，我们很容易实现一套满足ACID 特性的 事务处理系统， 事务的一致性不存在问题。 但是在分布式系统之中，由于数据分布在不同的主机结点上，如何对着些数据进行分布式的事务处理就具有非常大的挑战，CAP 理论的出现，让我们对于分布式事务的一致性有了另外一种看法。 什么是CAP 理论？ 在计算机科学理论，CAP 理论 （也称Brewer 定理） 又有称为 CAP原则，CAP定理，是由计算机科学家Eric Brewer 在 2000 年 提出的 ，其理论观点是， 在分布式计算机系统中，不可能存在同时提供 以下全部三个保证。 Consistency（一致性）： 所有节点同一时间看到的是相同的数据。在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） Availability（可用性）：不管是否成功，确保每一个请求都能接收到响应。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） Partition tolerance（分区容错性）：系统任意分区后，在网络故障时，仍能操作。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 　　 CAP原则是NOSQL数据库和分布式系统的基石。 为什么说CAP

1. resize root LVM (重置 centos root 分区大小) <!-- TOC --> 1. resize root (重置 root 分区大小) 1.1. 摘要 1.2. 操作 大功告成 参考文献 1.1. 摘要 安装centos7时使用默认分区，使用docker，运行 redis, mysql, jira, confluence, gitlab 2个月后，发现 root 分区空间不足，现有2种解决方案 * 方案一：将docker默认路径移至home目录下， 移动后，发现jira, confluence 无法启动 * 方案二：增加root LVM分区容量。（以下内容就是方案二的详细操作) 1.2. 操作 虚拟机进行快照 查看当前空间占用 [root@localhost ~]# df -h 文件系统 容量 已用 可用 已用% 挂载点 /dev/mapper/centos-root 50G 28G 23G 56% / devtmpfs 7.8G 0 7.8G 0% /dev tmpfs 7.8G 0 7.8G 0% /dev/shm tmpfs 7.8G 9.2M 7.8G 1% /run tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup /dev/sda1 1014M 276M 739M 28% /boot /dev/mapper

需要两台centos7主机 系统版本：CentOS Linux release 7.2.1511 NFS服务端：192.168.229.138 NFS客户端：192.168.229.136 1、首先配置在客户端和服务端分别配置编辑/etc/hosts文件： vim /etc/hosts 192.168.229.138 node100 192.168.229.136 node200 2、服务端操作 安装rpc服务（该服务相当于中介服务，用于获取nfs客户端的端口号） yum install nfs-utils rpcbind 启动rpc服务 systemctl start rpcbind.service 看服务是否启动：ps -ef|grep rpcbind rpc 76730 1 0 10:23 ? 00:00:00 /sbin/rpcbind -w root 100577 74436 0 16:56 pts/0 00:00:00 grep --color=auto rpcbind 然后再启动nfs服务 systemctl start nfs [root@localhost data]# ps -ef|grep nfs root 76875 2 0 10:24 ? 00:00:00 [nfsd4] root 76876 2 0 10:24 ? 00:00:00 [nfsd4

问题描述：有时候安装系统时，业务所在的分区太小，很容易导致分区爆满，而其他分区空闲，需要从其他分区挪空间过来或者新增磁盘扩容 需求分析： 分配的硬盘 50G ， /opt 分到为 19G ，随着业务的使用 /opt 文件系统已经达到 100% ，现在计划新分配 500G 的空间 方法一： 新增磁盘：已通过虚拟化控制台新增一块大小为 500G 的硬盘，重启系统识别确认。已识别到大小为 500G 的磁盘， 磁盘名称为 vdb （因为是虚拟机，所以是 vdx 名称格式） 文件系统扩容操作： 1、 查看卷组信息，只有一个 centos_hikvisionos 卷组且剩余空间为 40m 2、 查看逻辑卷信息， opt 逻辑卷属于 centos_hikvisionos 卷组且大小为 18.41g 3、 查看逻辑卷绝对路径 4、 新增磁盘 vdb 创建为物理卷 5、 物理卷扩容至 centos_hikvisionos 卷组内 6、 确认 centos_hikvisionos 卷组扩容后的剩余空间，由 40m 变为 500.04g 7、 opt 逻辑卷进行扩容，增加 300G 8、 opt 文件系统空间自动扩展 9、 查看确认文件系统大小， /opt 文件系统大小为 319G ，扩容成功 方法二： 从其他分区挪用，如从/home 检查文件系统类型以及空间使用情况 从上图得知： 报空间不足的

图片中可以看到挂载点“/”的利用率移到100%，空间不够，所以要对其进行分区。 1.先进入虚拟机设置里增大磁盘空间 注意：将25改成50，以扩大空间。这里一定要写比25大的数，因为他是“增加到”50GB，而不是“增加了25GB” 2. 下图可以看到，硬盘空间增大为53.7GB，在设备那里可以看到有两个分区，sda1跟sda2（请忽略sda3）。接下来增加一个分区。 键入命令：fdish /dev/sda 键入：n （增加分区） 键入：p（增加主分区） 键入：回车（起始跟结束扇区） 最后：w(退出) 注意：“起始扇区”那里直接回车，随便乱写容易造成空间浪费。 现在系统就有3个分：sda1,sda2,sda3 3. 创建物理卷 键入命令：pvcreate /dev/sda3 如果提示sda3找不到，键入：partprobe或者重启虚拟机。 4. 使用vgscan查询物理卷 4.1可以查到本机物理卷名称为“cl”， 4.2使用新增物理卷扩展cl： 键入命令：vgextendcl /dev/sda3 5. 扩展lv 键入命令：lvextend -L +24G 加上要扩展的分区名 接着用 dh –f，发现实际容量并没有变化，因为我们的系统还不认识刚刚添加进来的磁盘的文件系统，所以还需要对文件系统进行扩容。 键入：xfs_growfs 加上要扩展的分区名 或者 resize2fs –f 加

　　　　　　　　　　　　　　　　　 　《Kafka权威指南》读书笔记-操作系统调优篇 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰 版权声明：原创作品，谢绝转载！否则将追究法律责任。 　　大部分Linux发行版默认的内核调优参数配置已经能够满足大多数应用程序的运行需求，不过还是可以通过调整一些参数来进一步提升Kafka的性能。这些参数主要与虚拟内存，网络子系统和用来存储日志片段的磁盘挂在点有关。这些参数一般配置在“/etc/sysctl.conf” 文件里，不过在对内核参数进行调整时，最好参考官方提供的操作系统文档。 一.虚拟内存 　　一般来说，Linux的虚拟内存会根据系统的工作负荷进行自动调整。我们可以对交换分区的处理方式和内存脏页进行调整，从而让Kafka更好的处理工作负载。对于大多数依赖吞吐量的应用程序来说，要尽量避免内存交换。内存页和磁盘之间的交换对Kafka各方面的性能都有重大影响。kafka大量地使用系统页面缓存，如果虚拟内存被交换到磁盘，说明已经没有多余的内存可以分配该页面缓存啦。 1>.把vm.swappiness的值设置的更小一点（默认值是60，推荐设置为小于10的数字，比如1。） 　　一种避免内存交换的方法是不设置任何交换分区。内存交换不是必须的 ，不过它确实能够在操作系统发生灾难性错误时提供一些帮助

一、LVM概念 LVM是逻辑盘卷管理（Logical Volume Manager）的简称，它是Linux环境下对磁盘分区进行管理的一种机制，LVM是建立在硬盘和分区之上的一个逻辑层，来提高磁盘分区管理的灵活性。 LVM的工作原理其实很简单，它就是通过将底层的物理硬盘抽象的封装起来，然后以逻辑卷的方式呈现给上层应用。在传统的磁盘管理机制中，我们的上层应用是直接访问文件系统，从而对底层的物理硬盘进行读取，而在LVM中，其通过对底层的硬盘进行封装，当我们对底层的物理硬盘进行操作时，其不再是针对于分区进行操作，而是通过一个叫做逻辑卷的东西来对其进行底层的磁盘管理操作。比如说我增加一个物理硬盘，这个时候上层的服务是感觉不到的，因为呈现给上层服务的是以逻辑卷的方式。 LVM最大的特点就是可以对磁盘进行动态管理。因为逻辑卷的大小是可以动态调整的，而且不会丢失现有的数据。如果我们新增加了硬盘，其也不会改变现有上层的逻辑卷。作为一个动态磁盘管理机制，逻辑卷技术大大提高了磁盘管理的灵活性。 二、LVM术语 PV （Physical Volume）- 物理卷 物理卷在逻辑卷管理中处于最底层，它可以是实际物理硬盘上的分区，也可以是整个物理硬盘。 VG （Volumne Group）-卷组 卷组建立在物理卷之上，一个卷组中至少要包括一个物理卷，在卷组建立之后可动态添加物理卷到卷组中

基于UCloud云centos7.2_X64环境搭建docker-rancher-k8s微服务环境 docker与其它数据统一的保存在/data/目录中 只需远程执行如下脚本即可完成升级内核与安装Docker步骤 修改服务器主机名,这里推荐采用主机内网IP,'.'替换成'-'便于查看,使用如下命令 或者将主机名根据作用命名 如rancher服务负载均衡rancher-proxy 如rancher服务节点1,命名为rancher_node01 如rancher服务节点2,命名为rancher_node02 #例子 hostnamectl --static set-hostname xxx-xxx-xxx-xxx #rancher代理服务 hostnamectl --static set-hostname rancher-proxy #rancher服务节点1 hostnamectl --static set-hostname rancher-node01 #rancher服务节点2 hostnamectl --static set-hostname rancher-node02 #坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑坑 /etc/hosts文件下一定要增加一行 主机ip 主机名 例:192.168.10.100(ip) 192-168-10-100(主机名)

详解inode 索引节点（inode） 什么是inode：文件存储在硬盘上，硬盘最小单位为扇区，每个扇区大小为512字节 系统提高硬盘读取效率是一次连续读取多个扇区，而多个扇区整合一个块（block） 块就是文件存取最小单位，一个块大小4k，而文件属性、创建时间、权限、所占块大小、数量等这些信息即为inode信息 所以硬盘分区都有一个对应inode inode中信息包括： 文件类型、权限、UID、GID 链接数 文件大小和不同的时间戳 指向磁盘上文件的数据块指针 有关文件的数据 Inode特点 每个inode 大小均固定为128 bytes (新的ext4 与xfs 可设定到256 bytes)； 每个档案都仅会占用一个inode 而已； 承上，因此档案系统能够建立的档案数量与inode 的数量有关； 系统读取档案时需要先找到inode，并分析inode 所记录的权限与使用者是否符合，若符合才能够开始实际读取 block 的内容 使用命令：ls -i/ll -i Inode表结构如下图： 从上图 inode 结构表可以算出一下表结构图 inode和三个文件管理命令关系 cp和inode 分配一个空闲的inode号，在inode表中生成新条目 在目录中创建一个目录项，将名称与inode编号关联 拷贝数据生成新的文件 rm 和inode： 链接数递减，从而释放的inode号可以被重用