引言ceph自从到了L版本以后，L版本的启用，对性能本身有了极大的提高，一直对这个比较不放心的就是内存的占用，刚开始的时候记得大量dd就可以把内存搞崩掉，这个应该是内部的设计逻辑需要更多的内存的占用 最近在做ARM版本的服务器的测试，机器为36盘位的机器，内存需要自然多，但是36盘位的机器，按之前想法是4G预留，那得需要144G内存了，这个还没有算迁移的时候的内存消耗，而很多时候，我们并不需要速度，只需要稳定就好 测试环境说明测试环境比较简单，一台36盘位的arm机器，一台X86机器，通过万兆相连，设置集群为副本1，然后再X86上面通 限制前后对比我们先按默认的来一组测试 用读取命令进行测试 123456789101112131415161718192021222324rados -p rbd -t 64 bench 300 seq --run-name 4Mt16···2019-09-03 15:19:20.478841 min lat: 0.188154 max lat: 0.658198 avg lat: 0.227437 sec Cur ops started ...

前言在做一个管理平台的时候，面向客户的最开始的第一步就是管理平台的登陆系统，而由于面向的是企业用户，内网用户，因此，往往有很多我们预想不到的情况出现，而这些都会去影响着管理平台的体验，或者会完全中断掉你的操作 这里在分析一些做的比较好的平台后，以及结合我们自身可能遇到的情况，对登陆系统进行一个新的设计，这个是通用的设计并不针对某款产品 范例zabbix的登陆系统是做的比较好的，我们先来看看，然后再去给出我的设计 首页欢迎页面 通过欢迎页面可以看到，整个初始化大概有几个步骤，这个只要有明显的告知即可 检查先决条件 这个步骤是去检查环境是不是有问题，依赖的选项是不是正确的，这里可以把一些比较重要的调整参数或者默认的参数放到这里做检查，一个是给出的推荐值和一个当前的值，方便去检查 配置数据库连接 这一步是比较重要的一步，跟管理平台的可用性比较大，下面我们会介绍，这里给出了多种数据库的选择，这是因为平台支持，一般情况下就写死就行，数据库的主机名称，端口，数据库的名称，用户名，密码 这些都没问题 总览配置 刚刚做的配置，在这里做一次查看，确认下相关的信息，这样也方便做整体的二次审查 最终 ...

前言邮箱系统在提供了用户名和密码以后可以发送邮件，而在发送之前我们有个需求是需要验证下这个密码是不是正确的，本篇的内容就是用python默认的库来检测邮箱是不是可以登录的 验证这个采用的是python默认带的库smtplib，是一个发送邮件的库，脚本文件如下 123456789101112131415161718192021222324252627282930313233343536373839#! usr/bin/python# -*- coding: UTF-8 -*-import sysimport osusername=sys.argv[1]password=sys.argv[2]chinesname=sys.argv[3]import smtplibfrom email.mime.text import MIMETextmail_host = 'smtp.qq.com'mail_user = '%[email protected]' % usernamemail_pass = '%s' % password#print mail_ ...

前言服务器的服务做HA有很多种方式，其中有一种就是是用CTDB，之前这个是独立的软件来做HA的，现在已经跟着SAMBA主线里面了，也就是跟着samba发行包一起发行 之前CTDB的模式是需要有一个共享文件系统，并且在这个共享文件系统里面所有的节点都去访问同一个文件，会有一个Master会获得这个文件的锁 在cephfs的使用场景中可以用cephfs的目录作为这个锁文件的路径，这个有个问题就是一旦有一个节点down掉的时候，可能客户端也会卡住目录，这个目录访问会被卡住，文件锁在其他机器无法获取到，需要等到这个锁超时以后，其它节点才能获得到锁，这个切换的周期就会长一点了 CTDB在最近的版本当中加入了cluster mutex helper using Ceph RADOS的支持，本篇将介绍这个方式锁文件配置方式 实践过程安装CTDB1[root@customos ~]# yum install samba ctdb 检查默认包里面是否有rados的支持 1234567891011121314[root@customos ~]# rpm -qpl samba-4.8.3-4.el7.x86 ...

需求描述在某些测试场景下面，需要满足能够拔盘以后在插入的时候能够自动上线磁盘，这个需求实际在生产中是不建议使用的，原因是插入的磁盘如果本身存在问题，那么拉起的操作可能会破坏了本身集群的稳定性，所以这个算是一个测试相关的功能，但是做这个功能的前提是我们不要去影响了正常的环境的逻辑 类似的功能的开发都是应该去在外面做触发的也就是能够很方便的开启和关闭功能，整个功能也是集成到原来的环境当中的，原来怎么用，现在怎么用 实现的方式本次设计的方式是udev去截取lvm的设备的加载，如果直接截获磁盘的加载，这个在ceph bluestore里面是有问题的，因为bluestore采用的是lvm设备，这个是需要设备插入以后，再用一系列的触发，再去做相关的启动的 我们的设计方式是在lvm加载的时候去截取判断，是不是我们需要启动的信息 修改rule文件/usr/lib/udev/rules.d/69-dm-lvm-metad.rules这个在最后加上，如果不是我们ceph使用的设备，会在脚本里面去排除 12LABEL="lvm_end"R ...

问题文件从windows里面放到nginx里面去的时候，文件在windows下面是大小写忽略，也就是不论大小写都可以匹配的，而到linux下面的时候，因为linux是区分大小写的，也就是会出现无法忽略大小写的访问 调研通过nginx里面目前还没有找到实现的方式，通过插件的方式也只是能把大小写全部转换成小写，这样要让存储的文件的名称全部改成小写，这个不太适合去改变用户的文件 而apache里面有模块直接来实现这个，那么考虑有适用场景的时候，可以使用nginx加apache或者直接采用apache的方式，这个最好可以灵活的选择，不限定最好 实现方式修改配置文件/etc/httpd/conf/httpd.conf 12345678<Directory /> AllowOverride ALL CheckSpelling on CheckCaseOnly on Require all denied</Directory>LoadModule speling_module modules/mod_spelin ...

主流的操作系统 ubuntu centos debian oracle linux 主要使用的操作系统就是上面几个，主要是ubuntu和centos，debian是基于ubuntu改的，oracle linux是基于centos改的 操作系统介绍ubuntu操作系统ubuntu操作系统是主打桌面的一个操作系统，软件包的更新比较快，内核的版本用的比较新，如果软件系统都是采用的比较新的库和新的内核，那么可以考虑使用这个系统，当然缺点就是系统的维护周期较短，需要去比较频繁的升级来适应新的系统 Ubuntu每6个月发布一个新版，每个版本都有代号和版本号。版本号源自发布日期，例如第一个版本，4.10，代表是在2004年10月发行的 版本 开发代号 发布日期 支持结束时间 内核版本 4.1 Warty Warthog 2004/10/20 2006/4/30 2.6.8 5.04 Hoary Hedgehog 2005/4/8 2006/10/31 2.6.10 5.1 Breezy Badger ...

说明本篇主要记录iscsi的客户端的一些常用的一些操作 iscsi服务端常用操作删除一个lun 1tgtadm --lld iscsi --mode logicalunit --op delete --tid 2 --lun 1 新增一个lun 1tgtadm --lld iscsi --mode logicalunit --op new --tid 2 --lun 1 --backing-store rbd/test4M --bstype rbd --blocksize 2048 更新一个lun 1tgtadm --lld iscsi --mode logicalunit --op update --tid 2 --lun 1 --param "lbppbe=0" 常用的操作安装软件1yum install iscsi-initiator-utils 查询远端的iscsi target1iscsiadm -m discovery -t sendtargets -p 66.66.66.189 登陆指定的target1iscsiadm -m nod ...

前言之前在filestore里面，pg是直接暴露到文件系统的，也就是可以直接进去查看或者拷贝，在极端情况下，多个osd无法启动，pg无法导出的时候，那么对pg内部对象的操作处理，是可以作为最后恢复数据的一种方式的 这个在bluestore里面就没那么直接了，之前也碰到过一次，osd无法启动，内部死循环，pg无法export，osd就僵死在那里了，实际上，bluestore也提供了接口把对象能够直接显示出来 具体操作实践我们选择一个pg 1.7 123[root@lab101 ceph]# ceph pg dump|grep 1.7dumped all1.7 128 0 0 0 0 524353536 1583 1583 active+clean 2019-07-26 10:05:17.715749 14'3583 14:3670 [1] 1 [1] 1 0'0 2019-07-26 10:01:20.3 ...