重启后docker没法进行操作, 报 Cannot connect to the Docker daemon. Is the docker daemon running on this host?

因为Docker 运行的gitlab 把内存用光了,重新启动了下机器,然后多分了点内存给这台虚拟机,然后准备 docker start gitlab,结果报错

Cannot connect to the Docker daemon. Is the docker daemon running on this host?

然后才想起来,我擦。。。docker服务没有开机自启动,于是开一下docker的service

service docker start

或者

systemctl start docker

以上为centos/red hat 系列服务器指令。Ubuntu自查。

要是避免下次出这个问题,则需要添加到开机启动里。

systemctl enable docker

浅谈常用的几个raid,并着重讲讲raid 01和raid 10的区别

常用的几个raid 介绍

一、常用的初始raid等级

    (1) raid 0

raid 0 ,是一种简单、无数据效验的条带化技术。严格来说并不能算是真正raid,因为它没有提供数据的“冗余保护”。万一硬盘坏了,就全完了。

简单来说,就是把你的数据分散到两个(也可以是多个,也是按照一样的数据的分布模型)硬盘上,再并行化读取写入,从而提高IO性能,即1+1=2。(持续IO理论上是这样,小文件IO并不会有什么增长,也遇到过负增长的情况)

例如:原始数据是 A1、A2、A3、A4、A5、A6、A7、A8,在raid 0的情况下,就会分散到两个盘里,disk 0 存 A1、A3、A5、A7 ,disk 1存A2 、A4、A6、A8。普通的单盘,读取/写入这A1~A8的数据时,会需要8个读写周期。而raid 0情况下,因为两个盘会同步读取,即disk 0读A1时,disk1会同步读同样位置的A2,所以只要4个读写周期,就能完成A1~A8的数据操作,实现读写翻倍。

这个模式也可以应用于多盘硬盘RAID 0,比如你用8个盘做raid 0,每个盘分别存了A1~A8一节数据,那么只要一个读写周期就能读写完毕。raid 0的IO性能理论上是按照盘数叠加的(如果你的盘里没有特别慢拖后腿的盘),8盘raid+现在单碟1T盘普遍能达到持续IO 100M/S,则这组raid 0可以达到800M/S的持续IO。

然而理想很美好,现实很骨感。

首先是小文件的问题,raid 0 小文件基本基本不起作用。小文件和4K性能,基本上是机械硬盘的“硬伤”,因为限制住硬盘小文件IO和4K IO发挥的,主要是“寻道时间”。小文件放在不同磁道上,要来回切换磁道,浪费大量的时间,这个也同样在raid0上出现,没法解决,导致4K和小文件IO性能基本增长为0。

然后就是数据安全性的问题。如开头说的,它没有“冗余数据保护”。

即数据坏了就是坏了,只能视图找高价的专业数据恢复公司。有些人想着,坏了就是坏了,没关系,就像普通硬盘一样,拿着其他的好硬盘继续用? NO,回到当初的数据模型。。。原始数据是A1~A8,假设我们用了8盘raid 0,然后其中的第三块盘挂掉了,那么这段A1~A8的数据中,A3就永远缺失了,于是整段A1~A8数据彻底报废。。。raid 0 只要一块盘挂了,哪怕是意外掉线,都有可能搞得整个硬盘阵列组彻底挂掉。所以raid 0往往是一些硬件玩家用在个人PC上的方案,一般没什么人敢拿自己公司的生产数据去冒这个险。

(2) raid 1

raid 1跟raid 0很像,不过是另外一个极端。raid 0是只要速度,不要数据保护,没有冗余只有加速。而raid 1是不要速度,只要数据保护,只有冗余没有加速。

raid 1其实就是个“镜像”技术,比如本来写在单盘上的A1、A2、A3、A4,我同时在两个盘上都给写上去。这样,两块盘中,当有一块盘挂掉的时候,另一块盘可以立马接替工作(因为有100%完整一致的数据)。然后这个时候,你就能把原来的坏盘拔下来,再插一张新盘上去。如果是硬件raid 卡,则会自动rebuild,然后把数据热备到新盘上。过了一会,则新盘跟原来的老盘一样,有完整的全部数据了。整个过程中,硬盘阵列是一直在线的,不会影响正在跑的业务。但是rebuild热备到新硬盘的过程中,会对阵列性能有一定的影响。

如果是软 raid,则可能需要手动设置下,才能正常rebuild。还有,如果是关机了,再对硬盘进行替换,即便有硬件阵列卡,也不会进行自动rebuild,需要进一下raid卡管理界面配置后才能进行rebuild。所以最好还是开机运行中更换,不然业务中断也会造成不好影响。

这个比较适合做网站和小型数据库、小型应用之类的。毕竟raid 1上限就是2块盘,多盘意义不大(你给一块盘做多个备份意义不大,一个备份就够了,raid 1往往都能用到换机时还没坏)。所以适合不需要太大磁盘空间,但是对数据安全性比较敏感的商用环境。

(3) raid 5

无论是raid 0 也好,raid 1也好,这两个主流技术都偏向了极端,要么是要速度,没备份,要么有备份,没速度,有没有折中点,能提供加速,也能提供备份,同时不像raid 1一样浪费大把的磁盘空间?有! raid 5。

不过相对于raid 1而言,他并没有专门的硬盘来储存备份数据,而是分散式效验存储。如图,原有的数据是:A1、A2、A3、B1、B2、B3、C1、C2、C3、D1、D2、D3,而A1~A3的效验值为Ap,B1~B3的效验值为Bp,C1~C3的效验值为Cp,D1~D3的效验值为Dp。

然后把数据块和他们对应的效验块分散到不同的硬盘上,这样来规避安全风险。

比如Disk 2坏了,你插了新硬盘后,A3 将通过A1+A2数据块综合他们的条带效验值Ap来反算出来,然后重新存储进新的Disk 2, Bp是B1~B3的校验和,直接重新拿B1~B3算一次就好,C2也能通过C1+C3综合校验和Cp反酸,同理,D2也是一样能通过分散在其他盘的数据块+数据块的效验和反算。

简单来说,就是RAID 5损失了一块硬盘后。这块盘上储存的数据,因为分散存储了数据和校验和的原因,可以通过其他盘上分散存储的数据和校验和来彻底恢复损失盘上的数据。

这个方案看起来很不错,因为他的备份损失是N-1。即你用N块硬盘来加入raid 5的组合,会因为需要一块盘来存综合校验和(架设你把上面的Ap、Bp、Cp、Dp刚好全部挪到一个盘上,会发现刚好浪费一个盘的空间,不过肯定不能放到同一个盘上,这样刚好损失全部校验和或者全部数据的时候就GG了),所以会损失掉一个盘的空间,同时因为要产生存储IO无用、仅在效验的时候有用的校验和,在IO周期内,也会损失掉一个盘的IO性能,但是,剩下的空间和IO性能,却能在理论上都利用起来。

比如上图的4盘方案,可以利用3盘的空间,持续IO性能也理论上相当于3盘叠加,利用率很高。而使用4盘以上的时候,因为这个方案始终牺牲后的性能和存储容量为N-1,那么利用率肯定会越来越高。(利用率= N-1/N,肯定N越大越好,能无限接近于1)

但还是理想很美好,现实很残酷,这也是为什么RAID5往往还仅出现在硬件玩家的PC上和运维菜鸟的运维的服务器上。。。

https://www.cnblogs.com/wycc/p/6477351.html?utm_source=itdadao&utm_medium=referral

具体详情请参考上面那篇技术大牛的文章,我这里只把他的结论简单汇总下。

 

 

(施工中,未完待续,催更加Q 1637999484)

 

SVN定期更新 (crontab方法)

公司的生产环境中,有个项目将作为其他项目的支持库,来广泛引用。

之前都是每个人 svn co 一份在自己目录下,并定期svn up,来使用。但是该支持库的体积太大(大概88G),随便来几个人每个人拷贝一份,就有很大的磁盘空间浪费,且多人频繁svn up也会浪费大量带宽。。。

于是,打算除了这个“支持库”项目的开发者外,在linux服务器上新建一个公共目录,来统一存放支持库,大家需要的时候,直接引用这个目录下的支持库即可。这样就避免了磁盘空间浪费与svn带宽浪费,也少开了很多svn账号。

但是问题又来了,这个支持库需要定期更新,每次让他们要用时再上去svn up一下有点太过麻烦,于是干脆写个定期svn up的脚本,挂在服务器上跑着。

用到的工具:

1.定期svn up的带账号密码的svn脚本;

2.计划任务工具crontab;

脚本:

#!/bin/bash
cd /***/*** #请把/***/***替换为项目目录
export LC_CTYPE=en_US.UTF-8
svn up –username svn_user_name –password svn_user_passwd /***/*** #请把/***/***替换为项目目录,并把svn_user_name替换为你的svn用户名,svn_user_passwd更换为svn密码

注意,因为wordpress排版问题,脚本里有些莫名其妙的换行,请复制粘贴到本地再进行参考,以免错误多打换行。

编写完后,把脚本存起来,记得chmod +x 。

然后再在crontab里面添加定期任务

crontab -e #进入crontab任务编辑模式命令

添加这条定期任务

*/1 * * * * /***/***.sh #/***/***.sh请替换成自己的sh脚本路径,我这个脚本是每分钟执行一次

然后重启服务

service crond restart

即可完成定期任务

 

后记:

后面发现,由于没有重定向脚本输出,导致所有输出都到了用户邮件里,/var/spool/mail/$user 这里的内容堆得跟爆炸了一样。。。

所以,决定改一下crontab的内容,进行一下输出重定向。

*/1 * * * * /***/***.sh > /*****/***.log 2>&1 &

这里 /***/***.sh是脚本目录,之前我没注意,把shell放在了别人能访问到的位置。。。差点出事,这次注意点,我专门在根目录下新建了个root权限的 ‘.’开头的隐藏路径,免得别人有办法进来搞事情。 后面的/****/***.log 也请更换为自己的.log文件路径,也建议一样做隐藏。

 

后记追加(最终完美版):

还是发现有点弄得不爽。。。

这个crontab的输出是覆盖的,而不是追加的,也就是说万一有什么报错记录或者信息,立马就给你覆盖掉了,失去了记录消息的意义。。。

而且里面也不带时间,没法根据错误消息去回溯故障时间与故障log信息。

于是再来改一波

先修改crontab的输出方式,老规矩,crontab -e进入编辑模式

*/1 * * * * /***/***.sh >> /*****/***.log 2>&1 &

从原来的’>’ 改成了 ‘>>’ ,这样每次输出就是追加到文件尾部,而不是覆盖。

然后再把输出的脚本改的完美点,带上格式和时间戳。

修改shell脚本为:

#!/bin/bash
cd /***/***
export LC_CTYPE=en_US.UTF-8
echo ‘—————————————-‘
echo ‘- Start to running shell at -‘
date +”- %Y-%m-%d %H:%M.%S -”
echo ‘—————————————-‘
echo ‘Svn log:’
svn up –username svn_user_name –password svn_user_passwd /***/*** #请把/***/***替换为项目目录,并把svn_user_name替换为你的svn用户名,svn_user_passwd更换为svn密码
echo ‘—————————————-‘

添加了几个echo语句,这些本来要输出到console上面的信息,因为crontab中的重定向,被输出到文件了。并通过 date +带上了时间戳。以上脚本因粘贴到wordpress里面的时候因多余空格被过滤掉了,务必重新排版!

最终的输出结果

—————————————-
– Start to running shell at –
– 2018-08-02 14:38.01 –
—————————————-
Svn log:
At revision **.
—————————————-

最终完工!

 

后期更新计划:

1.写一篇 crontab的详解。

2.这个日志输出比较简单,好像还是覆盖输出,晚点写一个带日期时间的输出,添加到这篇文章的后记里,方便事后做故障查询。(已实现,追加到后记追加)

欢迎来到554的运维小站

欢迎来到554的运维小站

本人比较懒,会不定期的更新一部分运维经验和项目上来,但是不能保证更新频率。

贴出来的代码与项目已去除敏感信息、或该项目/代码已从生产环境淘汰。参考时如遇到问题,可以QQ联系我进行咨询,但不一定能帮你解决所有问题。

注意,因为wordpress排版问题,脚本里有些莫名其妙的换行,请复制粘贴到本地再进行参考,以免错误多打换行!

还有,windows下的换行是 /r/n , linux下的换行是/n,请勿在windows下编写脚本再移到linux下!!!非要这样的话,请转换格式!尽量只在linux环境下直接编写代码,vim是个好东西,谢谢!

QQ:1637999484

自建yum仓库(Centos6 版本 阿里云+epel)

起因:公司有屏蔽外网的高保密级生产内网,内有linux机器,但是装软件很麻烦,需要一个个上传rpm包,会导致依赖性检查地狱。于是打算建个yum软件仓库,来提供软件安装支持。

服务器内网IP:192.168.0.66(之后看到这个IP,请根据自己的软件仓库服务器更改此IP,建议按照后记的方法设置个域名绑定)

客户端系统版本:redhat-6.5,配置源为CentOS6+rhel

先通过yum装上要使用的工具

yum install createrepo yum-utils -y

然后创建个目录,用于存放yum仓库的文件,我的是在/home/yum/yum_ali_cloud/下,请自行修改,如果怕出问题就山寨我的目录好了。

既然要copy别人的软件源,就要选个速度尽量快+支持reposync的软件源仓库。这里选用的是阿里云。在/etc/yum.repos.d/ 路径下新建一个.repo文件,填入以下的阿里云软件源配置。

# CentOS-Base.repo

# The mirror system uses the connecting IP address of the client and the

# update status of each mirror to pick mirrors that are updated to and # geographically close to the client. You should use this for CentOS updates

# unless you are manually picking other mirrors.

#

# If the mirrorlist= does not work for you, as a fall back you can try the # remarked out baseurl= line instead.

#

#

[base] name=CentOS-$releasever – Base – mirrors.aliyun.com failovermethod=priority baseurl=http://mirrors.aliyun.com/centos/$releasever/os/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/os/$basearch/ #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os gpgcheck=1 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6 #released updates [updates] name=CentOS-$releasever – Updates – mirrors.aliyun.com failovermethod=priority baseurl=http://mirrors.aliyun.com/centos/$releasever/updates/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/updates/$basearch/ #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates gpgcheck=1 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6 #additional packages that may be useful [extras] name=CentOS-$releasever – Extras – mirrors.aliyun.com failovermethod=priority baseurl=http://mirrors.aliyun.com/centos/$releasever/extras/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/extras/$basearch/ #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras gpgcheck=1 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6 #additional packages that extend functionality of existing packages [centosplus] name=CentOS-$releasever – Plus – mirrors.aliyun.com failovermethod=priority baseurl=http://mirrors.aliyun.com/centos/$releasever/centosplus/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/centosplus/$basearch/ #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus gpgcheck=1 enabled=0 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6 #contrib – packages by Centos Users [contrib] name=CentOS-$releasever – Contrib – mirrors.aliyun.com failovermethod=priority baseurl=http://mirrors.aliyun.com/centos/$releasever/contrib/$basearch/ http://mirrors.aliyuncs.com/centos/$releasever/contrib/$basearch/ #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib gpgcheck=1 enabled=0 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6

 

因为服务器的系统也是redhat 6.5,这里的环境量$releasever 返回值不对,导致添加的yum源后报错,提示内容为无法访问对应网址。需要手动把$releasever替换为版本号6。(不要自作聪明,把$releasever替换为6.5,阿里云下的源好像已经汇总到6的大版本号了,6.5里面只有个readme,提示你修改成6)

也可以自己设置个环境变量,把releasever的值设置为6。

bash环境下的设置方式

export releasever=”6″

c-shell环境下的设置方式

setenv releasever 6

接下来继续添加rhel源,这个源里面包含大部分redhat的企业软件资源包

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm

然后进行yum缓存更新,把这两个软件源的软件列表缓存到本地

#先清除一波yum的缓存

yum clean all

#缓存软件列表

yum makecache

添加完毕,接下来cd到仓库目录,执行以下命令

reposync -r base

trpodunv -r epel

reposync -r extras

reposync -r updates

利用reposync指令,把源里面的4个源复制下来,于是会在仓库目录下多出来base、epel、extras、updates四个文件夹。

reposync的工作方式有点类似于rsync,是按差量进行比对的,可以中断后重传。截止发帖是,以上四个文件源文件夹大概有25G左右的体积,2万多个软件包,故同步下载的时候请注意时间,尽量不要用经常会断开连接的ssh客户端来跑,用nohup或者screen挂个后台会比较好。

建完之后就是创建YUM仓库了,打开这四个文件夹,每个文件夹里都跑一次create repo

createrepo ./

注意,是在base、epel这些文件夹里跑,时间比较长,请提前安排好任务和时间计划。

执行完毕后,这个目录就能当yum仓库了。接下来就是建立http服务,把这些内容通过http形式,提供给内网,这里用的是nginx。

yum -y install nginx

安装nginx完毕后,进入/etc/nginx/conf.d/,修改default.conf。

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
#root /usr/share/nginx/html;
autoindex on;
root /home/yum/yum_ali_cloud;
}

里面的 root /home/yum/yum_ali_cloud表示把目录设定到我们的yum仓库目录。

做到这一步,已经把我们的yum仓库搭建完毕了,但是事情还没完,还要给内网的其他机器添加我们这台服务器的本地源。到他们的/etc/yum.repos.d/添加一个新的repo文件,例如:local.repo

[base]
name=CentOS-Base(GDS)
baseurl=http://192.168.0.66/base
path=/
enabled=1
gpgcheck=0

[updates]
name=CentOS-Updates(GDS)
baseurl=http://192.168.0.66/updates
path=/
enabled=1
gpgcheck=0

[epel]
name=Redhat-enterprise(epel)
baseurl=http://192.168.0.66/epel
path=/
enabled=1
gpgcheck=0

[extras]
name=CentOS-Extras(GDS)
baseurl=http://192.168.0.66/extras
path=/
enabled=1
gpgcheck=0

192.168.0.66为服务器装好后你配的内网地址,务必为固定地址,免得以后自动分配IP导致IP变动,无法访问yum服务器。

也可以把地址

然后把这个/etc/yum.repos.d/文件夹下之前的yum源给删掉,反正你以后用不到他们了,没必要留在里头添乱。再进行yum缓存更新

yum clean all

yum makecache

enjoy!

 

后记:

把IP设置为192.168.0.66这个固定IP的方法有点蠢,其实最好方法应该是把以上的192.168.0.66绑定一个域名(比如 yum.****.com  ,***可以是公司名,反正只在内网生效,随便取),然后通过修改/etc/hosts 的方式来实现本地的域名解析。

这样,万一服务器需要更换IP了,编辑一下hosts文件,再挂到HTTP服务器上(偷懒的话,可以直接挂到yum服务器的HTTP服务目录内),每个linux主机再去手动wget一下即可。

hosts实例(请按照格式添加到hosts文件尾部):

192.168.0.66 yum.yourcompany.com

将0.66这个IP改成你自己的yum服务器IP, 域名可以随便按喜好取,符合规范即可。