ceph

常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。 Google学术论文，这是众多分布式文件系统的起源 ================================== Google File System（大规模分散文件系统） MapReduce （大规模分散FrameWork） BigTable（大规模分散数据库） Chubby（分散锁服务） 一般你搜索Google_三大论文中文版(Bigtable、 GFS、 Google MapReduce)就有了。 做个中文版下载源：http://dl.iteye.com/topics/download/38db9a29-3e17-3dce-bc93-df9286081126 做个原版地址链接： http://labs.google.com/papers/gfs.html http://labs.google.com/papers/bigtable.html http://labs.google.com/papers/mapreduce.html GFS（Google File System） --------------------------------------

[toc] Kubernetes之（二）核⼼技术概念和API对象 API对象是Kubernetes集群中的管理操作单元。 Kubernetes集群系统每⽀持⼀项新功能， 引⼊⼀项新技术， ⼀定会新引⼊对应的API对象， ⽀持对该功能的管理操作。 例如副本集Replica Set对应的API对象是RS。 每个API对象都有3⼤类属性： 元数据metadata、 规范spec和状态status。 元数据是⽤来标识API对象的， 每个对象都⾄少有3个元数据： namespace， name和uid； 除此以外还有各种各样的标签labels⽤来标识和匹配不同的对象， 例如⽤户可以⽤标签env来标识区分不同的服务部署环境， 分别⽤env=dev、 env=testing、 env=production来标识开发、 测试、⽣产的不同服务。 规范描述了⽤户期望Kubernetes集群中的分布式系统达到的理想状态（Desired State） ， 例如⽤户可以通过复制控制器Replication Controller设置期望的Pod副本数为3； status描述了系统实际当前达到的状态（Status） ， 例如系统当前实际的Pod副本数为2； 那么复制控制器当前的程序逻辑就是⾃动启动新的Pod， 争取达到副本数为3。 Kubernetes中所有的配置都是通过API对象的spec去设置的， 也就是

ceph集群部署不难，只是集群如果比较庞大磁盘比较多的时候，前期准备很大的工作量：主机名，防火墙，yum源，ceph软件，免密，数据盘和日志盘分配。自己写了点小脚本可以实现“一键部署”（前提是所有节点之前网络畅通写能访问外网） 链接：https://pan.baidu.com/s/1e7EUXpdoLpIYcZsgXIIv0Q 提取码：3tzs 需要自己做的就三步：（所有操作只在运行脚本的节点上，其他服务器不用做任何配置） 1 规划节点 哪些是mon节点，哪些是osd节点。都写在./config/host 文件里面（了解ansible的同学都一眼都能看懂哈） 2 修改服务器节点hosts 根据上面1的规划，编辑/etc/hosts 。做好节点名称解析。（/etc/hosts的编辑再简单不过了就不多说了） 3 规划磁盘 在代码目录下./disk 下有很多目录（都代表了每一个节点）。把目录名字改成节点名称，目录中的stat.txt 中都写好osd 磁盘盘符，ssd.txt 都写好节点下的日志盘符。（默认wal_log 分区和db_log 分区 比例是3:2） 如需帮助查看readme.txt 声明：小脚本还有不完善的地方，比如管理网络和集群网络分离还没有实现。只做参考。 来源： oschina 链接： https://my.oschina.net/wangzilong/blog

【今日推荐】：为什么一到面试就懵逼！>>> 机器学习与容器化平台 愿景 算法同学爽、工程任务开心、技术快速复用，干完战，早点下班。总结了一下具体包括以下几个方面： 开发流程标准化 针对开发者，尤其是新人能够快速进入到开发工作中来， 前提是需要一套比较完善、合理的开发流程，将可能的开发工作流程集中在平台当中，在此基础上完成开发流程的标准化管控， 和军队培训战士一样， 我们从广大人民群众中，选择了最优秀的那一批同学，来到我们的团队，从内务教令、文化教育、长途越野跑、基础实战能力，到最后的兵王，一定是有一套特别完善的标准化流程，Goblin就想做这样的"军队"试验场，将人才的培养、项目开发上线，流程化、标准化，赋能给技术团队，让"新兵"得到最好的实践锻炼，"兵王"打好战； 能力接受与放大器 在大数据、算法团队中，其实很难评估开发人员本身的工作，最近在看一本书， 其中提到针对一个推荐系统产品，有4个关键元素需要注意： 1. UI和UE；2.数据；3.领域知识；4.算法，其权重是1>2>3>4，1和3是"颜值即正义"、"老天赏饭吃"， 2、4是我们开发者需要关注的，而对数据、算法，最难的其实是目标的定制，如何评估一个数据任务、大数据产品、算法模型有价值，需求方说好就一定好？指标升了就一定好？这个不一定，而这也是数据相关从业人员很有挑战的方面，而作为内部平台，算法、工程人员前方打战

Mon服务检查 查看对应进程是否在cgroup策略里面 OSD服务检查 来源： oschina 链接： https://my.oschina.net/u/97044/blog/402341

重启cgroup服务 service cgconfig restart 重启mon和osd服务 service ceph-mon-all restart service ceph-osd-all restart 来源： oschina 链接： https://my.oschina.net/u/97044/blog/402340

节点cpu和内存节点查看 准备配置文件 编辑/etc/cgconfig.conf 注意mon和osd部分根据实际情况进行增加 以下为配置文件 mount { cpu = /sys/fs/cgroup/cpu; cpuacct = /sys/fs/cgroup/cpuacct; cpuset = /sys/fs/cgroup/cpu; devices = /sys/fs/cgroup/devices; memory = /sys/fs/cgroup/memory; freezer = /sys/fs/cgroup/freezer; } group mon { perm { task { uid = root; gid = root; } admin { uid = root; gid = root; } } cpu { cpuset.cpus = 0; cpuset.mems = 0; } memory { memory.limit_in_bytes = 2g; memory.memsw.limit_in_bytes = 3g; memory.soft_limit_in_bytes = 1g; memory.swappiness = 0; memory.oom_control = 1; memory.failcnt = 1; } } group osd0 { perm { task

一、 Cgroup介绍 Cgroup是什么 Cgroups是control groups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程组（process groups）所使用的物理资源（如：cpu,memory,IO等等）的机制。最初由google的工程师提出，后来被整合进Linux内核。Cgroups也是LXC为实现虚拟化所使用的资源管理手段，可以说没有cgroups就没有LXC。 Cgroup能做什么 Cgroups最初的目标是为资源管理提供的一个统一的框架，既整合现有的cpuset等子系统，也为未来开发新的子系统提供接口。现在的cgroups适用于多种应用场景，从单个进程的资源控制，到实现操作系统层次的虚拟化（OS Level Virtualization）。Cgroups提供了一下功能： 限制进程组可以使用的资源数量（Resource limiting ）。比如：memory子系统可以为进程组设定一个memory使用上限，一旦进程组使用的内存达到限额再申请内存，就会出发OOM（out of memory）。 进程组的优先级控制（Prioritization ）。比如：可以使用cpu子系统为某个进程组分配特定cpu share。 记录进程组使用的资源数量（Accounting ）。比如：可以使用cpuacct子系统记录某个进程组使用的cpu时间 进程组隔离

ceph迁移有很多种方案。最简单的就是上一台新的，拆一台旧的。但是这样的方法不安全，有可能在数据迁移到一半的时候出现异常而老的数据在迁移回去费时费力而且又可能出现新的问题。所以今天分享一个比较安全的迁移方案。 1 设计方案 1.1 准备硬件 硬件准备包括安装操作系统，防火墙关闭，插入磁盘，分配网络，安装ceph软件。 1.2 迁移规划 迁移前： 主机 IP 组件 ceph-admin 172.18.0.131 mon,osd ceph-node1 172.18.0.132 mon,osd ceph-node2 172.18.0.133 mon,osd 迁移后： 主机 IP 组件 ceph-admin 172.18.0.131 mon ceph-node1 172.18.0.132 mon ceph-node2 172.18.0.133 mon transfer01 172.18.0.135 osd transfer02 172.18.0.34 osd transfer03 172.18.0.51 osd 2 迁移原理 迁移原理基于ceph 的crush 伪随机原理。简单的说就是当副本数增加的时候原来bucket中的数据不迁移，只是拷贝一份副本到新的bucket中。当副本数减少的时候 也是把指定的bucket中的数据删除，其他bucket中的数据不会迁移。 2.1

K8S : Helm 部署 ELK 7.6 场景 ​ 在 K8S 上部署有状态应用 ELK，收集日常测试数据的上报（应用拨测的 Heartbeat、调用链追踪的 APM、性能指标 metabeat 等）。本文通过rook提供底层存储，用于安装elk的statefulset，然后部署MetalLB实现本地负载均衡，最后通过ingress-control实现访问kibana。 操作步骤 1.安装rook 2.安装helm 3.安装ES 4.安装kibana 5.安装filebeat 6.安装metalLB 7.安装Ingress-control 8.访问测试 1.安装rook 1.1 安装说明 ​ Rook是专用于Cloud-Native环境的文件、块、对象存储服务。它实现了一个自我管理的、自我扩容的、自我修复的分布式存储服务。Rook支持自动部署、启动、配置、分配（provisioning）、扩容/缩容、升级、迁移、灾难恢复、监控，以及资源管理。为了实现所有这些功能，Rook依赖底层的容器编排平台。 ​ Ceph是一个分布式存储系统，支持文件、块、对象存储，在生产环境中被广泛应用。 ​ 此次安装就是通过rook进行ceph进行部署，简化了ceph的安装管理配置。同时也是为了能够利用本地资源。提供storageclass。 1.2 rook和ceph架构 1.2 安装ceph