分类目录归档:未分类

Linux本地源制作

1.centos7本地yum源制作:

(1)test

[base]
name=CentOS-$releasever - base
baseurl=ftp://10.101.1.41/yum_repo
gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

(2) repoquery是yum扩展工具包yum-utils中的一个工具,所有如果你没有repoquery命令的话,可以先 sudo yum install yum-utils 安装yum-utils包。是为了加强和补充yum功能的工具,重点是查询包的关系。https://www.cnblogs.com/JMLiu/p/7692784.html

(3)指定路径:cachedir=/mnt/usb_disk/yum-repo

         开启缓存:Keepcache=1  //1缓存  0不缓存

(4)生成repodata目录,自动创建索引信息 ,否则会报错“failed to retrieve packages”https://www.cnblogs.com/hailun1987/p/9827329.html

createrepo -pdo /yum/yum-custom/ /yum/yum-custom/
yum clean all
yun makecache

(5)clean参数

clean命令的选项:
下面指定你的clean命令的运行方式。这里命令中的“所有文件”实际就是当前被激活的软件仓库中的所有文件。如果你临时想要清除其他非激活的软件仓库中的内容,那么使用 --enablerepo='*'选项。
yum clean expire-cache
当元数据和每个软件仓库中的镜像列表下载的时候,删除本地的数据。也就是说,yum将会为每一个软件仓库刷新缓存。下次会使用到。但是如果缓存的数据仍然有用,那么不会删除任何重要的数据。
yum clean packages
从系统中删除任何缓存的软件包。我们需要注意的是当我们下载软件包之后,软件包并不会被自动地删除。
yum clean headers
删除所的头文件,这些头文件用于yum解决软件的以来关系。
yum clean metadata
删除yum用于确定软件包可用的一些文件(元数据文件)。使用这个选项会强制让yum下次运行的时候下载所有的元数据。
yum clean dbcache
删除sqlite缓存,这个缓存用来以很快的速度访问原数据。使用这个选项将会使得yum在下次运行的时候重新创建缓存文件。
yum clean all
删除上面说过的所的内容。

##########遇到问题##############

1.配置好vsftd,然而匿名访问的目录却为空; –selinux导致的;

#########附录########

以下两个命令可以列出RPM包的依赖情况,
1 yum deplist pakcage
2 rpm -qR package

###########参考附录:

https://www.cnblogs.com/nidey/p/6200685.html

–挂载U盘: https://www.cnblogs.com/kerrycode/archive/2013/04/01/2993744.html

2.Debian9本地apt源制作:

(1)创建文件夹,并把deb文件复制到该目录下,例如

mkdir -p /opt/apt_pkgs
cp -r /var/cache/apt/archives/* /opt/apt_pkgs

(2)建立Packages.gz包,里面记录了packs文件夹下面的软件包信息,包括依赖信息。

dpkg-scanpackages apt_pkgs /dev/null |gzip > apt_pkgs/Packages.gz -r

(3)修改sources.list为本地源:

deb file:///opt/apt/ apt_pkgs/
(注意三根斜杠,最后包目录前有一个空格)

(4)更新源:

sudo apt-get update

(5)内网源:

–先查看下是否已经安装apache2:service apache2 status

ln -s /opt/apt/apt_pkgs /var/www/html/apt_pkgs
ln -s /opt/apt_pkgs /var/www/html/apt_pkgs

–访问测试:http://127.0.0.1/apt_pkgs

(6)客户端配置:

deb [arch=amd64] http://127.0.0.1/ apt_pkgs/   ##空格注意,和本地配置一样

##########参考########

https://blog.csdn.net/metallicqi/article/details/51147832

–内网源配置:https://blog.csdn.net/sinat_36544290/article/details/82153524

lvs+keepalived+nginx实战

################几个名词解释###############

名称
缩写
全拼
说明
VIP
虚拟IP
virtual ip address
VIP为Director用于向客户端计算机提供服务的IP地址,如:www.test.com域名就要解析到vip上提供服务
RIP
真实IP地址
Real Server Ip Address
在集群下面节点上使用的IP地址,物理IP地址
DIP
Director
Director IP Address
用于连接内外网络的IP地址,物理网卡上的IP地址,是负载均衡器上的IP
CIP
客户端主机地址
Client IP address
客户端用户计算机请求集群服务器的IP地址,该地址用作发送给集群的请求的源IP地址

2.关于ip_forward:

IP地址分为公有ip地址和私有ip地址,Public Address是由INIC(internet network information center)负责的,这些IP地址分配给了注册并向INIC提出申请的组织机构。Private Address属于非注册地址,专门为组织内部使用。Private Address是不可能直接用来跟WAN通信的,要么利用帧来通信(FRE帧中继,HDLC,PPP),要么需要路由的转发(nat)功能把私有地址转换为公有地址才行。出于安全考虑,Linux系统默认是禁止数据包转发的。所谓转发即当主机拥有多于一块的网卡时,其中一块收到数据包,根据数据包的目的ip地址将数据包发往本机另一块网卡,该网卡根据路由表继续发送数据包。这通常是路由器所要实现的功能。

首先内网主机向外网主机发送数据包,由于内网主机与外网主机不在同一网段,所以数据包暂时发往内网默认网关GIP处理,而本网段的主机对此数据包不做任何回应。由于内网主机的SIP是私有的,禁止在公网使用,所以必须将数据包的SIP修改成公网上的可用IP,这就是网关收到数据包之后首先要做的事情--IP地址转换。然后网关再把数据包发往外网主机。外网主机收到数据包之后,只认为这是网关发送的请求,并不知道内网主机的存在,更不知道源IP地址是SIP而不是FIP,也没必要知道,目的主机处理完请求,把回应信息发还给网关的FIP。网关收到后,将目的主机返回的数据包的目标IP即FIP修改为发出请求的内网主机的IP地址即SIP,并根据路由表将其发给内网主机。这就是网关的第二个工作--数据包的路由转发。内网主机只要查看数据包的DIP与发送请求的SIP相同,就会回应,这就完成了一次请求。

3.关于Linux Pam:https://www.cnblogs.com/hftian/p/6944133.html

--PAM 为了实现其插件功能和易用性,它采取了分层设计思想:让各鉴别模块从应用程序中独立出来,然后通过PAM API作为两者联系的纽带,这样应用程序就可以根据需要灵活地在其中"插入"所需鉴别功能模块,从而真正实现了"鉴别功能,随需应变"。
--PAM验证模块的配置文件,存放位置 /etc/security中,如pam_limits.so验证模块对应的配置文件limits.conf,pam_group.so验证模块对应的配置文件group.conf。
PAM验证模块和应用程序的对应关系,存放位置/etc/pam.d文件夹。通过修改此文件夹下的配置文件,可以为应用选定具体的验证模块
--要使/etc/security/limits.conf 文件配置生效,必须要确保 PAM验证模块pam_limits.so 文件被加入到启动文件中。查看 /etc/pam.d/login 文件中有:
session  required  /lib/security/pam_limits.so
--64位地址是:/lib64/security/pam_limits.so 否则本地即使输入正确密码也无法登陆。

配置文件格式:
语法:Service  model_type  control_flag  model_path  options
--Service :使用PAM验证模块的应用程序,如ftp、telnet、login等。其中other一行指本文件中没有单独列出的其他应用程序;
-----验证模块的类型,主要有以下几种 auth :鉴别类模块   account:账户类模块   session:会话类模块       password:口令类模块
--Control_flag:对模块验证成功或者失败的结果的处理情况
-----Required:该模块验证成功是用户通过鉴别的必要条件。只有当应用程序对应的所有带有required标记的模块全部成功后,该应用程序才能通过 鉴别。同时,如果任何带有         required标记的模块出现了错误,PAM并不立刻将错误信息返回给应用程序,而是在所有模块都调用完毕后,再将错误信息返回给调用它的应用程序。
-----Requisite:与required相似,只有带有此标记的模块返回成功后,用户才能通过鉴别,不同之处在于,一旦失败就不再执行堆中后面的其他模块,并且鉴别过程到此结束。----------Optiona: 即使该模块验证失败,用户仍能通过鉴别。在PAM体系中,带有该标记的模块失败后,将继续处理下一模块。
Limits文件限制用户进程解析
PAM验证模块/lib/security/pam_limits.so主要是限制用户会话过程中对各种系统资源的使用。其对应的配置文件/etc/security/limits.conf其格式为:
Domain  type item
用户名/组名软/硬限制 项目
Domain:指被限制的用户名或组
Soft:当前系统生效的设置值(soft限制不能比hard限制高)
-      :同时设置了soft和hard的值
data——最大数据大小(KB)
memlock——最大可用内存空间(KB)
nofile——最大可以打开的文件数量
stack——最大堆栈空间(KB)
nproc——最大运行进程数
maxlogins——用户可以登录到系统最多次数
环境变量文件/etc/profile的更改也是为了修改对当前用户的进程限制。
-n:设置内核可以同时打开的文件描述符的最大值。
-u:设置用户最多可开启的程序数目。
数据段长度:ulimit -d unlimited
最大内存大小:ulimit -m unlimited
堆栈大小:ulimit -s unlimited
CPU 时间:ulimit -t unlimited。
虚拟内存:ulimit -v unlimited

(4)ifconfig命令:

---BROADCAST,MULTICAST,UP,LOWER_UP > 是net_device flags,网络设备的状态标识。UP 表示网卡处于启动的状态;BROADCAST 表示这个网卡有广播地址,可以发送广播包;MULTICAST 表示网卡可以发送多播包;LOWER_UP 表示 L1 是启动的,即网线插着。MTU1500 最大传输单元 MTU 为 1500,这是以太网的默认值。
---网络包是层层封装的。MTU 是二层 MAC 层的概念。MAC 层有 MAC 的头,以太网规定连 MAC 头带正文合起来,不允许超过 1500 个字节。正文里面有 IP 的头、TCP 的头、HTTP 的头。如果放不下,就需要分片来传输。
---

#######################################################

1.ipvsadm安装:

(1)编译环境准备:

yum install libnl* libpopt* -y
yum install popt-static -y

(2)安装:

tar -zxvf ipvsadm-1.26.tar.gz
cd ipvsadm-1.26
make
make install

(3)使用:https://blog.csdn.net/scape1989/article/details/21085659

ipvsadm:
      1、管理集群服务
           添加:-A -t|u|f service-address [-sscheduler]
                      -t:tcp协议的集群服务
                      -u:udp协议的集群
                      -f:FWM:防火墙标记
           修改:-E
           删除:-D
                      -D -t|u|f service-address    
                   例如:# ipvsadm -A -t 172.16.100.1:80 -s rr
      2、管理集群服务中的RS
           添加:-a -t|u|f service-address -rserver-address [-g|i|m] [-w weight]
                      -t|u|f service-address:事先定义好的某集群服务
                      -r server-address:某RS的地址,在NAT模型中,可以使用IP:PORT事先端口映射
                      [-g|i|m]:LVS类型
                           -g:DR
                           -I:TUN
                           -m:NAT
                      [-w weight]:定义服务器权重
       3、修改:-e
       4、删除:-d -t|u|f service-address -r server-address
                   例如:#ipvsadm -a -t 172.16.100.1:80 -r192.168.10.8 -m
                   例如:#ipvsadm-a -t 172.16.100.1:80 -r 192.168.10.9 -m
       5、查看
                    -L|l[options]
                           -n:数字格式显示主机地址和端口号
                           --stats:统计信息
                           --rate:速率
                           --timeout:显示tcp、tcpfin和udp会话的超时时间值
                           --daemon
                           --sort:跟协议、地址、端口进行排序,默认为升序
                           -c:显示当前ipvs连接状况
       6、删除所有集群服务:
                    -C:清空ipvs规则
       7、保存规则
                    -S:(用输出重定向进行保存)
                    格式:#ipvsadm -s >/path/to/somefile
       8、载入此前的规则:
                    -R
                     格式:#ipvsadm -R </path/to/somefile

2.keepalived安装:至于启动哪一个,主要是依据优先级,然后才根据设定的主备关系进行;

(1)编译环境准备:

yum -y install gcc gcc-c++ make popt-devel kernel-devel openssl-devel libnl libnl-devel

(2)安装:

tar -zxvf keepalived-2.0.12.tar.gz
cd keepalived-2.0.12
./configure
make && make install
cp keepalived/etc/init.d/keepalived /etc/init.d/
cp /usr/local/etc/sysconfig/keepalived  /etc/sysconfig/
systemctl enable keepalived
mkdir  -p  /etc/keepalived
cp /usr/local/sbin/keepalived /usr/sbin/

(3)keepalived.conf配置文件:由于采用dr模式,所以前后端口必须一致;

–master_example

! Configuration File for keepalived
global_defs {
router_id LVS_01 //本服务器的名称
}
vrrp_instance VI_1 { //定义VRRP热备实例
state MASTER //热备状态,MASTER表示主服务器,BACKUP表示从服务器
interface ens33 //承载VIP地址的物理接口
virtual_router_id 51 //虚拟路由器的ID号,每个热备组保持一致
priority 110 //优先级,数值越大优先级越高
advert_int 1 //通告间隔秒数(心跳频率)
authentication { //热备认证信息,每个热备组保持一致
auth_type PASS //认证类型
auth_pass 6666 //密码字符串
}
virtual_ipaddress { //指定漂移地址(VIP),可以有多个
10.101.1.100
}
}
virtual_server 10.101.1.100 8888 { //虚拟服务器地址(VIP)、端口
delay_loop 6 //健康检查的间隔时间(秒)
lb_algo rr //轮询(rr)调度算法
lb_kind DR //直接路由(DR)群集工作模式
persistence_timeout 60 //连接保持时间(秒)
protocol TCP //应用服务器采用的是TCP协议
real_server 10.101.1.70 8888 { //第一个Web服务器节点的地址、端口
weight 1 //节点的权重
TCP_CHECK { //健康检查方式
connect_port 8888 //检查的目标端口
connect_timeout 3 //连接超时(秒)
nb_get_retry 3 //重试次数
delay_before_retry 3 //重试间隔
}
}
real_server 10.101.1.59 8888 { //第二个Web服务器节点的地址、端口
weight 1
TCP_CHECK {
connect_port 80
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}

–master

! Configuration File for keepalived
global_defs {
router_id LVS_01
}
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 51
priority 110
advert_int 1
authentication {
auth_type PASS
auth_pass 6666
}
virtual_ipaddress {
10.101.1.100
}
}
virtual_server 10.101.1.100 8880 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 60
protocol TCP
real_server 10.101.1.59 8880 {
weight 1
TCP_CHECK {
connect_port 8880
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 10.101.1.187 8880 {
weight 1
TCP_CHECK {
connect_port 8880
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}

–backup

! Configuration File for keepalived
global_defs {
router_id LVS_02
}
vrrp_instance VI_1 {
state BACKUP
interface em1
virtual_router_id 51
priority 105
advert_int 1
authentication {
auth_type PASS
auth_pass 6666
}
virtual_ipaddress {
10.101.1.100
}
}
virtual_server 10.101.1.100 8880 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 60
protocol TCP
real_server 10.101.1.59 8880 {
weight 1
TCP_CHECK {
connect_port 8880
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 10.101.1.187 8880 {
weight 1
TCP_CHECK {
connect_port 8880
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}

(4)启动:systemctl start keepalived:

<span style="font-size: 9pt; color: rgb(51, 51, 51); font-family: Monaco;"–<日志:tail -f /var/log/messages:

Feb 13 05:50:32 jumpserver Keepalived[51727]: Starting Keepalived v2.0.12 (01/25,2019), git commit v2.0.11-47-gce6cf748+
Feb 13 05:50:32 jumpserver Keepalived[51727]: Running on Linux 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 (built for Linux 3.10.0)
Feb 13 05:50:32 jumpserver Keepalived[51727]: Command line: '/usr/local/sbin/keepalived' '-D'
Feb 13 05:50:32 jumpserver Keepalived[51727]: Opening file '/etc/keepalived/keepalived.conf'.
Feb 13 05:50:32 jumpserver Keepalived[51728]: Starting Healthcheck child process, pid=51729
Feb 13 05:50:32 jumpserver Keepalived[51728]: Starting VRRP child process, pid=51730
Feb 13 05:50:32 jumpserver systemd: Started LVS and VRRP High Availability Monitor.
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: Registering Kernel netlink reflector
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: Registering Kernel netlink command channel
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: Opening file '/etc/keepalived/keepalived.conf'.
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: Assigned address 10.101.1.70 for interface ens33
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: Assigned address fe80::a280:336:15f:676 for interface ens33
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: Registering gratuitous ARP shared channel
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: (VI_1) removing VIPs.
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: (VI_1) Entering BACKUP STATE (init)
Feb 13 05:50:32 jumpserver Keepalived_vrrp[51730]: VRRP sockpool: [ifindex(2), family(IPv4), proto(112), unicast(0), fd(11,12)]
Feb 13 05:50:32 jumpserver Keepalived_healthcheckers[51729]: Opening file '/etc/keepalived/keepalived.conf'.
Feb 13 05:50:32 jumpserver Keepalived_healthcheckers[51729]: (Line 30) Unknown keyword 'nb_get_retry'
Feb 13 05:50:32 jumpserver Keepalived_healthcheckers[51729]: (Line 39) Unknown keyword 'nb_get_retry'
Feb 13 05:50:32 jumpserver Keepalived_healthcheckers[51729]: Gained quorum 1+0=1 <= 2 for VS [10.101.1.100]:tcp:8880
Feb 13 05:50:32 jumpserver Keepalived_healthcheckers[51729]: Activating healthchecker for service [10.101.1.59]:tcp:8880 for VS [10.101.1.100]:tcp:8880
Feb 13 05:50:32 jumpserver Keepalived_healthcheckers[51729]: Activating healthchecker for service [10.101.1.187]:tcp:8880 for VS [10.101.1.100]:tcp:8880
Feb 13 05:50:36 jumpserver Keepalived_healthcheckers[51729]: TCP connection to [10.101.1.187]:tcp:8880 success.
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: (VI_1) Receive advertisement timeout
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: (VI_1) Entering MASTER STATE
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: (VI_1) setting VIPs.
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: (VI_1) Sending/queueing gratuitous ARPs on ens33 for 10.101.1.100
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:36 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:38 jumpserver Keepalived_healthcheckers[51729]: TCP connection to [10.101.1.59]:tcp:8880 success.
Feb 13 05:50:41 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:41 jumpserver Keepalived_vrrp[51730]: (VI_1) Sending/queueing gratuitous ARPs on ens33 for 10.101.1.100
Feb 13 05:50:41 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:41 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:41 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 13 05:50:41 jumpserver Keepalived_vrrp[51730]: Sending gratuitous ARP on ens33 for 10.101.1.100

(5)主从同步测试:可以看到VIP在主备之间进行切换;

---停掉master keepalived:
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: (VI_1) Backup received priority 0 advertisement
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: (VI_1) Receive advertisement timeout
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: (VI_1) Entering MASTER STATE
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: (VI_1) setting VIPs.
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: (VI_1) Sending/queueing gratuitous ARPs on ens33 for 10.101.1.100
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:44 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:49 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:49 localhost Keepalived_vrrp[55841]: (VI_1) Sending/queueing gratuitous ARPs on ens33 for 10.101.1.100
Feb 12 08:04:49 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:49 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:49 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
Feb 12 08:04:49 localhost Keepalived_vrrp[55841]: Sending gratuitous ARP on ens33 for 10.101.1.100
---重新启动master
Feb 12 08:05:27 localhost Keepalived_vrrp[55841]: (VI_1) Master received advert from 10.101.1.70 with higher priority 110, ours 105
Feb 12 08:05:27 localhost Keepalived_vrrp[55841]: (VI_1) Entering BACKUP STATE
Feb 12 08:05:27 localhost Keepalived_vrrp[55841]: (VI_1) removing VIPs.

3.nginx安装:

(1)编译环境准备:

sudo yum check-update || sudo yum update -y
sudo yum groupinstall -y 'Development Tools' && sudo yum install -y vim
sudo yum install -y epel-release
sudo yum install -y perl perl-devel perl-ExtUtils-Embed libxslt libxslt-devel libxml2 libxml2-devel gd gd-devel GeoIP GeoIP-devel
sudo yum -y install zlib zlib-devel openssl openssl--devel pcre pcre-devel
yum -y install gcc gcc-c++ make popt-devel kernel-devel openssl-devel

(2)安装:

tar -xzf nginx-1.15.7.tar.gz
cd nginx-1.15.7
sed -i -e 's/1.15.7//g' -e 's/nginx\//TDTWS/g' -e 's/"NGINX"/"TDTWS"/g' src/core/nginx.h
./configure --prefix=/usr/local/nginx  --with-http_stub_status_module  --with-http_ssl_module --with-stream --with-stream_ssl_module
make
make install
/usr/sbin/groupadd -f www
/usr/sbin/useradd -g www www

(3)启动:启动前可以用-t参数判断下配置文件是否有问题,或者直接在启动参数中添加-t;修改配置文件可以用./nginx -s reload

/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

(4)停止

--从容停止:ps -ef|grep nginx ;kill -QUIT 2072
--快速停止:kill -TERM 2132 或 kill -INT 2132
--强制停止:pkill -9 nginx

(5)管理和升级:

#查看nginx进程
ps -ef|grep nginx
#平滑启动nginx
kill -HUP `cat /var/run/nginx.pid`
或者
nginx -s reload
其中进程文件路径在配置文件nginx.conf中可以找到。
平滑启动的意思是在不停止nginx的情况下,重启nginx,重新加载配置文件,启动新的工作线程,完美停止旧的工作线程。
#完美停止nginx
kill -QUIT `cat /var/run/nginx.pid`
#快速停止nginx
kill -TERM `cat /var/run/nginx.pid`
或者
kill -INT `cat /var/run/nginx.pid`
#完美停止工作进程(主要用于平滑升级)
kill -WINCH `cat /var/run/nginx.pid`
#强制停止nginx
pkill -9 nginx
#检查对nginx.conf文件的修改是否正确
nginx -t -c /etc/nginx/nginx.conf 或者 nginx -t
#停止nginx的命令
nginx -s stop或者pkill nginx
#查看nginx的版本信息
nginx -v
#查看完整的nginx的配置信息
nginx -V

—升级:分为四个步骤,包括软件下载、预编译、编译、配置

wget http://www.nginx.org/download/nginx-1.4.2.tar.gz
获取旧版本nginx的configure选项
/usr/local/nginx/sbin/nginx -V
编译新版本的Nginx
tar  -xvf  nginx-1.4.2.tar.gz
cd nginx-1.4.2
./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-stream --with-stream_ssl_module
make
备份旧版本的nginx可执行文件,复制新版本的nginx这行文件
mv /usr/local/nginx/sbin/nginx  /usr/local/nginx/sbin/nginx.old
cp objs/nginx /usr/local/nginx/sbin/
测试新版本nginx是否正常
/usr/local/nginx/sbin/nginx -t
平滑重启升级nginx
kill -QUIT `cat /usr/local/nginx/log/nginx.oldbin` ##关闭旧版nginx
验证nginx是否升级成功
/usr/local/nginx/sbin/nginx  -V显示最新编译的版本信息即可。

—重新编译添加新模块:

进入nginx源码目录
cd nginx-1.3.2
以下是重新编译的代码和模块
./configure --prefix=/usr/local/nginx--with-http_stub_status_module --with-http_ssl_module --with-file-aio --with-http_realip_module
make 千万别make install,否则就覆盖安装了
make完之后在objs目录下就多了个nginx,这个就是新版本的程序了
备份旧的nginx程序
cp /usr/local/nginx/sbin/nginx/usr/local/nginx/sbin/nginx.bak
把新的nginx程序覆盖旧的
cp objs/nginx /usr/local/nginx/sbin/nginx
测试新的nginx程序是否正确
/usr/local/nginx/sbin/nginx -t
nginx: theconfiguration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx:configuration file /usr/local/nginx/conf/nginx.conf test issuccessful
平滑重启nginx
/usr/local/nginx/sbin/nginx -s reload
查看ngixn版本极其编译参数
/usr/local/nginx/sbin/nginx -V

4.dr模式测试:realserver上必须启动脚本,将loIP地址设置成VIP的地址

#!/bin/sh
#LVS Client Server
VIP=192.1.105.200
case  $1  in                                                                                                                                                                                                                     
start)                                                                                                                                                                                                                           
    ifconfig lo:0 $VIP netmask 255.255.255.255 broadcast $VIP
    /sbin/route add -host $VIP dev lo:0
    echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
    echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
    echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
    echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
    sysctl -p >/dev/null 2>&1
    echo "RealServer Start OK"
    exit 0
;;                                                                                                                                                                                                                               
stop)
    ifconfig lo:0 down
    route del $VIP >/dev/null 2>&1
    echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore
    echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce
    echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore
    echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
    echo "RealServer Stoped OK"
    exit 1
;;
*)
    echo "Usage: $0 {start|stop}"
;;
esac

###############几个问题##############搬运工###################

(1)让lvs server和real server工作在同一台服务器上:https://www.douban.com/note/598634431/

(2)LVS的几个重点知识:http://www.360doc.com/content/14/0918/15/1123425_410457105.shtml

(3)DR原理详细介绍:https://blog.csdn.net/liupeifeng3514/article/details/79038451  https://www.cnblogs.com/leezhxing/p/4613500.html

1.DR数据流向:现在客户端CLient访问www.a.com ,经过dns查询得到目的IP为VIP,目的端口为80,于是客户端和我们VIP,端口80建立连接(TCP三次握手,只是建立连接没有传送数据),之后客户端发送HTTP请求,LVS在VIP上收到之后,根据hash策略,从后端realserver中选出一台作为此次请求的接受者,假设为RIP1,LVS将请求包的目的mac地址更改为RIP1的mac,然后封装后转发给后端的RIP1,同时将该链接记录在hash表中。RIP1的某一块网卡,比如eth0,接收到这个转发包看到mac地址是自己的,于是就转发给上层的IP层,IP层解开包后,发现目的的IP地址也是自己,因为VIP也配置在我们的一块non-arp的网卡上(比如lo:0),然后根据IP首部的类型字段(这里是TCP),把请求送给TCP,然后TCP根据目的端口80,传给应用层的Apache,Apache处理完请求之后,将数据传给TCP,TCP将源端口更改为80 ,源IP更改为VIP,目的端口更改为客户端的端口,目的IP更改为Client的IP,打包后给IP层,IP层根据目的地址进行路由,然后经过网络返给Client,完成了一次请求,而不经过LB;
2.DR模式的优缺点
优点:
    可扩展性强,ld不会成为业务增长的瓶颈
缺点:
    节点不能跨网段,即real server和ld必须在一个物理网段中,一定程度上可能会使用多个公网IP
    realserver上须有一块网卡不接受arp广播
3.DR模式与arp,由于DR模式使用的是更改目的的mac地址,所以难免要和arp打交道。arp -a可以查看当前服务器上面的arp缓存;https://www.jianshu.com/p/a682ecae9693
一般来说客户端是不会和我们的服务器在同一个网段的,那么请求就会经过我们的服务器所在网段的路由设备上,我们知道在同一网段中,两个主机通信靠的是二层的物理地址而不是Ip地址,所以当请求包到达这路由设备上之后,若路由设备的arp表中没有VIP对应的
MAC,就会广播一个arp请求,在这里我们将LVS和real server上都配置了VIP,那么按照理论他们都会响应这个arp请求,那路由器的arp表就会乱了。所以,我们就需要只让LVS上响应VIP的arp请求,而real server 不响应;Linux主机有这么一个特性,假设我们的主机上有两块网卡,比如eth0,eth1 当arp请求eth1的mac地址的时候,eth1会答复,这个是理所当然的,但是eth0也会“好心”的帮eth1回答这个arp请求; 要防止这样的话,就需要更改下我们的一些内核参数:

    net.ipv4.conf.lo.arp_ignore = 1

    net.ipv4.conf.all.arp_ignore = 1

正常情况下只写第二条就是了,all 是指所有设备的interface,当all和具体的interface比如lo,按照最大的值生效;另外一个linux的特性就是,对于一个从realserver发出的arp请求,其源IP是VIP,而出口不会是lo,这里假设是eth0,那么这个arp请求包里里面,源IP就是VIP,源MAC是eth0的mac,目的IP是网关,那么路由器在接收到这个请求的时候,会将将自己的相应接口的硬件地址放在arp响应包中,同时将请求包中的源IP及MAC放在arp高速缓存中,那这下可就乱套 了,就会使真正的VIP得不到正确的请求了.这是因为,正常的情况下,arp的请求中源IP是出去的所在接口的地址,mac也是出去的接口的mac,但linux在默认情况下却不是这样的,如果一个接口发出的arp请求须经另一个出口出去的时候,源IP就不是所出去接口的IP,那么将内核参数设置为 2 相应的解决了这个问题。

    net.ipv4.conf.lo.arp_announce = 2

    net.ipv4.conf.all.arp_announce = 2
2.PC1的网卡收到bit流,通过网卡解封装,查看数据报文中目的MAC地址为本机的MAC,继续解封装,查看目的IP地址为自己的IP地址,继续解封装,查看TCP报文,通过查看源端口,确定是与PC2连接的端到端连接,在解封装,发现为FTP报文,提交给上层协议进行处理,应用程序通过读取FTP报文,把报文返回到输出界面。

(4)tcpdump抓包:tcpdump -i eth1 port 80 -Xx(注:如果没有tcpdump,就yum -y install tcpdump)   wireshark查看;

(5)关于loopback回环端口,回环接口可以配置,而且是一个网络号,并非主机号,除非把掩码配置为32bits。https://blog.csdn.net/yydcj/article/details/8447567

Loopback接口是虚拟接口,是一种纯软件性质的虚拟接口。任何送到该接口的网络数据报文都会被认为是送往设备自身的。大多数平台都支持使用这种接口来模拟真正的接口。这样做的好处是虚拟接口不会像物理接口那样因为各种因素的影响而导致接口被关闭。事实上,将Loopback接口和其他物理接口相比较,可以发现Loopback接口有以下几条优点:
1.       Loopback接口状态永远是up的,即使没有配置地址。这是它的一个非常重要的特性。    
2.       Loopback接口可以配置地址,而且可以配置全1的掩码,可以节省宝贵的地址空间。    
3.       Loopback接口不能封装任何链路层协议。
IP协议中的loopback地址。RFC2606中明确指出了loopback地址的标准域名为localhost。在IPv4中,其对应的IP地址一直是127.0.0.1;理论上,整个127IP段(127.0.0.0~127.255.255.255)的IP地址都为loopback地址,与localhost对应。在IPv6中,localhost对应的IP地址为0:0:0:0:0:0:0:1,一般写作::1。
在网络设备中,loopback被用来代表某些用于管理目的的虚拟接口,其含义并没有"回环"的意思。loopback虚拟接口会分配到一个IP地址,但是这个IP地址不会对应到实际的物理接口。网络设备中的loopback地址主要用于管理目的,例如设备发出的报警。网络设备中的应用程序(管理程序)使用loopback地址发送可接收数据流,而不是使用实际物理接口的地址。对外部来说,直接使用loopback地址来查看设备对应的信息(如报警信息),与网卡的物理地址无关。。我们也可以把这种地址理解为网络设备提供的服务的地址。
在通信领域,loopback可以用作将接收到的信号或数据直接返回给发送者的测试方法。作为一种测试方法,很多通信设备都可以配置端口的数据发送模式(例如all ones模式),来检测同一个端口上的信号接收。这种测试也叫"回环测试"。

(6)关于手动添加ipvsadm规则删除:http://www.mamicode.com/info-detail-121656.html

#删除vip地址
  /sbin/ifconfig eth0:0 down
#关闭ip转发
  echo 0 > /proc/sys/net/ipv4/ip_forward
#清除ipvsadm 规则
  /sbin/ipvsadm -C
#删除锁文件
  /bin/touch $LOCKFILE
ipvsadm  -A  -t  10.101.1.100:8880  -s  rr
ipvsadm  -a  -t  10.101.1.100:8880  -r  10.101.1.59  -g  -w 2
ipvsadm  -a  -t  10.101.1.100:8880  -r  10.101.1.187  -g  -w 2
ipvsadm  -D  -t  10.101.1.100:8880
ipvsadm  -d  -t  10.101.1.100:8880  -r  10.101.1.59
ipvsadm  -d  -t  10.101.1.100:8880  -r  10.101.1.187

(7)安装配置:https://www.cnblogs.com/a-can/p/123ddd.html   https://www.cnblogs.com/liuyisai/p/5990645.html

(8)采坑专业户:http://baijiahao.baidu.com/s?id=1585299978849584757&wfr=spider&for=pc

(9)抓包分析网络问题:https://www.cnblogs.com/shizouwei/p/9072186.html

(10)网桥工具brctl使用:https://blog.csdn.net/skh2015java/article/details/82466718

(11)dnsmasq服务:http://blog.51cto.com/yanconggod/1977598  haproxy:https://www.linuxidc.com/Linux/2018-04/151871.htm

#################分割线####################遇到问题即解决:

1.报错:./configure: error: the HTTP rewrite module requires the PCRE library.

—sudo yum -y install zlib zlib-devel openssl openssl–devel pcre pcre-devel

2.报错:Nginx错误:[emerg] getpwnam(“www”) failed  原因:没有创建WWW这个用户;

/usr/sbin/groupadd -f www 
/usr/sbin/useradd -g www www

3.查看内核版本: uname -sr

4.报错:ip_vs.h:15:29: fatal error: netlink/netlink.h: No such file or directory

yum install libnl* libpopt* -y
yum install popt-static -y

5.Nginx: Too Many Open Files 错误和解决方案,主要原因是Linux / Unix 设置了软硬文件句柄和打开文件的数目:https://www.cnblogs.com/kevingrace/p/5815592.html

(1)临时生效方法:
--ulimit -n 30000   // 用ulimit -n 30000 修改只对当前的shell有效,退出后失效。
--nginx.conf文件添加:worker_rlimit_nofile 30000;
(2)永久生效:
---修改硬件配置:在nginx服务器可以打开的文件数量受你操作系统的限制,编辑/etc/sysctl.conf 添加如下内容:
    fs.file-max = 70000 保存退出,重新读取系统配置sysctl -p
    再编辑 /etc/security/limits.conf 添加内容:
    * soft nofile 10000
    * hard nofile 30000
    此修改内容需要reboot系统才能生效,所以务必从新启动下服务器。
---修改Nginx系统的文件限制,使用nginx worker_rlimit_nofile Option
    # set open fd limit to 30000
    worker_rlimit_nofile 30000;
    sudo service nginx reload
(3)查看命令:
    ulimit -Hn
    ulimit -Sn
ulimit : 设置最大进程数和最大文件打开数, 这个一般是系统优化的必要手段.
1) 临时修改
为了优化linux性能,可能需要修改这个最大值。临时修改的话ulimit -n 655360就可以了,重启后失效。
[root@localhost ~]# ulimit -n
1024
[root@localhost ~]# ulimit -n 655360
[root@localhost ~]# ulimit -n
655360
2) 永久修改
修改/etc/security/limits.conf文件, 在文件末尾添加
[root@localhost ~]# vim /etc/security/limits.conf
* soft nofile 655360
* hard nofile 655360
* soft nproc 655360
* hard nproc 655360
=============================
上面配置内容中:
*               代表针对所有用户
noproc     是代表最大进程数
nofile      是代表最大文件打开数
如上修改后重启服务或服务器,如果发现没更改过来, 还需要修改下面梁文文件
在/etc/security/limits.d/90-nproc.conf文件末尾添加
[root@localhost ~]# vim /etc/security/limits.d/90-nproc.conf
* soft nproc 655360
* hard nproc 655360
在/etc/security/limits.d/def.conf文件末尾添加
[root@localhost ~]# vim /etc/security/limits.d/def.conf
* soft nofile 655360
* hard nofile 655360
然后重启后生效

6.主备都有VIP:(VI_1) Received advert from 10.101.1.70 with lower priority 110, ours 115, forcing new election

—抓包发现主备都在进行VRRP广播:tcpdump -i em1 vrrp -n,正常情况下备机进行vrrp广播只可能是没有收到master的心跳包,查看发现备机防火墙将信息拦截了;

—抓包要带上网口-i,否则报错:tcpdump: NFLOG link-layer type filtering not implemented

############################内容跟进###############################################

1.keepalived简介:https://blog.csdn.net/qq_24336773/article/details/82143367

--Keepalived是Linux下一个轻量级别的高可用解决方案,高可用(High Avalilability,HA),其实两种不同的含义:广义来讲,是指整个系统的高可用行,狭义的来讲就是之主机的冗余和接管,它与HeartBeat RoseHA 实现相同类似的功能,都可以实现服务或者网络的高可用,但是又有差别,HeartBeat是一个专业的、功能完善的高可用软件,它提供了HA 软件所需的基本功能,比如:心跳检测、资源接管,检测集群中的服务,在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大,但是部署和使用相对比较麻烦,与HeartBeat相比,Keepalived主要是通过虚拟路由冗余来实现高可用功能,虽然它没有HeartBeat功能强大,但是Keepalived部署和使用非常的简单,所有配置只需要一个配置文件即可以完成;
--Keepalived起初是为LVS设计的,专门用来监控集群系统中各个服务节点的状态,它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态,如果某个服务器节点出现异常,或者工作出现故障,Keepalived将检测到,并将出现的故障的服务器节点从集群系统中剔除,这些工作全部是自动完成的,不需要人工干涉,需要人工完成的只是修复出现故障的服务节点,后来Keepalived又加入了VRRP的功能,VRRP(Vritrual Router Redundancy Protocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题,通过VRRP可以实现网络不间断稳定运行,因此Keepalvied 一方面具有服务器状态检测和故障隔离功能,另外一方面也有HA cluster功能,下面介绍一下VRRP协议实现的过程;
--VRRP协议与工作原理:在现实的网络环境中,主机之间的通信都是通过配置静态路由或者(默认网关)来完成的,而主机之间的路由器一旦发生故障,通信就会失效,因此这种通信模式当中,路由器就成了一个单点瓶颈,为了解决这个问题,就引入了VRRP协议,熟悉网络的学员对VRRP协议应该不陌生,它是一种主备模式的协议,通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信,这其中涉及到两个概念:物理路由器和虚拟路由器;VRRP可以将两台或者多台物理路由器设备虚拟成一个虚拟路由,这个虚拟路由器通过虚拟IP(一个或者多个)对外提供服务,而在虚拟路由器内部十多个物理路由器协同工作,同一时间只有一台物理路由器对外提供服务,这台物理路由设备被成为:主路由器(Master角色),一般情况下Master是由选举算法产生,它拥有对外服务的虚拟IP,提供各种网络功能,如:ARP请求,ICMP 数据转发等,而且其它的物理路由器不拥有对外的虚拟IP,也不提供对外网络功能,仅仅接收MASTER的VRRP状态通告信息,这些路由器被统称为“BACKUP的角色”,当主路由器失败时,处于BACKUP角色的备份路由器将重新进行选举,产生一个新的主路由器进入MASTER角色,继续提供对外服务,整个切换对用户来说是完全透明的;每个虚拟路由器都有一个唯一的标识号,称为VRID,一个VRID与一组IP地址构成一个虚拟路由器,在VRRP协议中,所有的报文都是通过IP多播方式发送 的,而在一个虚拟路由器中,只有处于Master角色的路由器会一直发送VRRP数据包,处于BACKUP角色的路由器只会接受Master角色发送过来的报文信息,用来监控Master运行状态,一一般不会发生BACKUP抢占的情况,除非它的优先级更高,而当MASTER不可用时,BACKUP也就无法收到Master发过来的信息,于是就认定Master出现故障,接着多台BAKCUP就会进行选举,优先级最高的BACKUP将称为新的MASTER,这种选举角色切换非常之快,因而保证了服务的持续可用性;
3》Keepalvied的工作原理:上面我们介绍了Keepalived通过VRRP实现高可用性的工作原理,而Keepalived作为一个高性能集群软件,它还能实现对集群中服务器运行状态的监控以及故障隔离,下面我们介绍一下Keepalived对服务器运行状态和故障隔离的工作原理;Keepalived工作在TCP/IP 参考模型的 三层、四层、五层,也就是分别为:网络层,传输层和应用层,根据TCP、IP参数模型隔层所能实现的功能,Keepalived运行机制如下:
--在网络层: 我们知道运行这4个重要的协议,互联网络IP协议,互联网络可控制报文协议ICMP、地址转换协议ARP、反向地址转换协议RARP,在网络层Keepalived在网络层采用最常见的工作方式是通过ICMP协议向服务器集群中的每一个节点发送一个ICMP数据包(有点类似与Ping的功能),如果某个节点没有返回响应数据包,那么认为该节点发生了故障,Keepalived将报告这个节点失效,并从服务器集群中剔除故障节点;
--在传输层: 提供了两个主要的协议:传输控制协议TCP和用户数据协议UDP,传输控制协议TCP可以提供可靠的数据输出服务、IP地址和端口,代表TCP 的一个连接端,要获得TCP服务,需要在发送机的一个端口和接收机的一个端口上建立连接,而Keepalived在传输层里利用了TCP协议的端口连接和扫描技术来判断集群节点的端口是否正常,比如对于常见的WEB服务器80端口。或者SSH服务22端口,Keepalived一旦在传输层探测到这些端口号没有数据响应和数据返回,就认为这些端口发生异常,然后强制将这些端口所对应的节点从服务器集群中剔除掉;
--在应用层:可以运行FTP,TELNET,SMTP,DNS等各种不同类型的高层协议,Keepalived的运行方式也更加全面化和复杂化,用户可以通过自定义Keepalived工作方式,例如:可以通过编写程序或者脚本来运行Keepalived,而Keepalived将根据用户的设定参数检测各种程序或者服务是否允许正常,如果Keepalived的检测结果和用户设定的不一致时,Keepalived将把对应的服务器从服务器集群中剔除;
Keepalived 是运行在lvs 之上,它的主要功能是实现真实机的故障隔离及负载均衡器间的失败 切换,提高系统的可用性;

–基本架构:

SchedulerI/OMultiplexer是一个I/O复用分发调度器,它负载安排Keepalived所有内部的任务请求;
Memory Mngt是一个内存管理机制,这个框架提供了访问内存的一些通用方法;
Control Plane 是keepalived的控制版面,可以实现对配置文件编译和解析;
Core componets 这部分主要包含了5个部分;
Watchdog:是计算机可靠领域中极为简单又非常有效的检测工具,Keepalived正是通过它监控Checkers和VRRP进程的。
Checkers:这是Keepalived最基础的功能,也是最主要的功能,可以实现对服务器运行状态检测和故障隔离。
VRRP Stack:这是keepalived后来引用VRRP功能,可以实现HA集群中失败切换功能。负责负载均衡器之间的失败切换FailOver;
IPVS wrapper:这个是IPVS功能的一个实现,IPVSwarrper模块将可以设置好的IPVS规则发送的内核空间并且提供给IPVS模块,最终实现IPVS模块的负载功能。
Netlink Reflector:用来实现高可用集群Failover时虚拟IP(VIP)的设置和切换,
keepalived运行时,会启动3个进程,分别为:core(核心进程),check和vrrp
- core:负责主进程的启动,维护和全局配置文件的加载;
- check:负责健康检查
- vrrp:用来实现vrrp协议

–与Heartbeat、Corosync比较:

Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好,Heartbeat、Corosync是属于同一类型,Keepalived与Heartbeat、Corosync,根本不是同一类型的。Keepalived使用的vrrp虚拟路由冗余协议方式;Heartbeat或Corosync是基于主机或网络服务的高可用方式;简单的说就是,Keepalived的目的是模拟路由器的高可用,Heartbeat或Corosync的目的是实现Service的高可用。
  所以一般Keepalived是实现前端高可用,常用的前端高可用的组合有,就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用,常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。总结一下,Keepalived中实现轻量级的高可用,一般用于前端高可用,且不需要共享存储,一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用,且需要共享存储,一般用于多节点的高可用。

–配置文件:keepalived.conf:http://outofmemory.cn/wiki/keepalived-configuration

—–global_defs区域主要是配置故障发生时的通知对象以及机器标识:

global_defs {
     notification_email {
         a@abc.com
         b@abc.com
         ...     }
     notification_email_from alert@abc.com
     smtp_server smtp.abc.com
     smtp_connect_timeout 30
     enable_traps
     router_id host163
 }
* notification_email 故障发生时给谁发邮件通知。
* notification_email_from 通知邮件从哪个地址发出。
* smpt_server 通知邮件的smtp地址。
* smtp_connect_timeout 连接smtp服务器的超时时间。
* enable_traps 开启SNMP陷阱(Simple Network Management Protocol)。
* router_id 标识本节点的字条串,通常为hostname,但不一定非得是hostname。故障发生时,邮件通知会用到。

—–static_ipaddress和static_routes区域配置的是是本节点的IP和路由信息。如果你的机器上已经配置了IP和路由,那么这两个区域可以不用配置。其实,一般情况下你的机器都会有IP地址和路由信息的,因此没必要再在这两个区域配置。

—–vrrp_script区域用来做健康检查的,当时检查失败时会将vrrp_instance的priority减少相应的值。

vrrp_script chk_http_port {
     script "</dev/tcp/127.0.0.1/80"
     interval 1
     weight -10
 }
以上意思是如果script中的指令执行失败,那么相应的vrrp_instance的优先级会减少10个点。

——vrrp_instance用来定义对外提供服务的VIP区域及其相关属性。

——vrrp_rsync_group用来定义vrrp_intance组,使得这个组内成员动作一致。举个例子来说明一下其功能:两个vrrp_instance同属于一个vrrp_rsync_group,那么其中一个vrrp_instance发生故障切换时,另一个vrrp_instance也会跟着切换(即使这个instance没有发生故障)。

vrrp_sync_group VG_1 {
     group {
         inside_network   # name of vrrp_instance (below)
         outside_network  # One for each moveable IP.
         ...
     }
     notify_master /path/to_master.sh
     notify_backup /path/to_backup.sh
     notify_fault "/path/fault.sh VG_1"
     notify /path/notify.sh
     smtp_alert
 }
 vrrp_instance VI_1 {
     state MASTER
     interface eth0
     use_vmac <VMAC_INTERFACE>
     dont_track_primary
     track_interface {
         eth0
         eth1
     }
     mcast_src_ip <IPADDR>
     lvs_sync_daemon_interface eth1
     garp_master_delay 10
     virtual_router_id 1
     priority 100
     advert_int 1
     authentication {
         auth_type PASS
         auth_pass 12345678
     }
     virtual_ipaddress {
         10.210.214.253/24 brd 10.210.214.255 dev eth0
         192.168.1.11/24 brd 192.168.1.255 dev eth1
     }
     virtual_routes {
         172.16.0.0/12 via 10.210.214.1
         192.168.1.0/24 via 192.168.1.1 dev eth1
         default via 202.102.152.1
     }
     track_script {
         chk_http_port
     }
     nopreempt
     preempt_delay 300
     debug
     notify_master <STRING>|<QUOTED-STRING>
     notify_backup <STRING>|<QUOTED-STRING>
     notify_fault <STRING>|<QUOTED-STRING>
     notify <STRING>|<QUOTED-STRING>
     smtp_alert
 }
* notify_master/backup/fault 分别表示切换为主/备/出错时所执行的脚本。
* notify 表示任何一状态切换时都会调用该脚本,并且该脚本在以上三个脚本执行完成之后进行调用,keepalived会自动传递三个参数($1 = "GROUP"|"INSTANCE",$2 = name of group or instance,$3 = target state of transition(MASTER/BACKUP/FAULT))。
* smtp_alert 表示是否开启邮件通知(用全局区域的邮件设置来发通知)。
* state 可以是MASTER或BACKUP,不过当其他节点keepalived启动时会将priority比较大的节点选举为MASTER,因此该项其实没有实质用途。
* interface 节点固有IP(非VIP)的网卡,用来发VRRP包。
* use_vmac 是否使用VRRP的虚拟MAC地址。
* dont_track_primary 忽略VRRP网卡错误。(默认未设置)
* track_interface 监控以下网卡,如果任何一个不通就会切换到FALT状态。(可选项)
* mcast_src_ip 修改vrrp组播包的源地址,默认源地址为master的IP。(由于是组播,因此即使修改了源地址,该master还是能收到回应的)
* lvs_sync_daemon_interface 绑定lvs syncd的网卡。
* garp_master_delay 当切为主状态后多久更新ARP缓存,默认5秒。
* virtual_router_id 取值在0-255之间,用来区分多个instance的VRRP组播。
可以用这条命令来查看该网络中所存在的vrid:tcpdump -nn -i any net 224.0.0.0/8
* priority 用来选举master的,要成为master,那么这个选项的值最好高于其他机器50个点,该项取值范围是1-255(在此范围之外会被识别成默认值100)。
* advert_int 发VRRP包的时间间隔,即多久进行一次master选举(可以认为是健康查检时间间隔)。
* authentication 认证区域,认证类型有PASS和HA(IPSEC),推荐使用PASS(密码只识别前8位)。
* virtual_ipaddress vip,不解释了。
* virtual_routes 虚拟路由,当IP漂过来之后需要添加的路由信息。
* virtual_ipaddress_excluded 发送的VRRP包里不包含的IP地址,为减少回应VRRP包的个数。在网卡上绑定的IP地址比较多的时候用。
* nopreempt 允许一个priority比较低的节点作为master,即使有priority更高的节点启动。
首先nopreemt必须在state为BACKUP的节点上才生效(因为是BACKUP节点决定是否来成为MASTER的),其次要实现类似于关闭auto failback的功能需要将所有节点的state都设置为BACKUP,或者将master节点的priority设置的比BACKUP低。我个人推荐使用将所有节点的state都设置成BACKUP并且都加上nopreempt选项,这样就完成了关于autofailback功能,当想手动将某节点切换为MASTER时只需去掉该节点的nopreempt选项并且将priority改的比其他节点大,然后重新加载配置文件即可(等MASTER切过来之后再将配置文件改回去再reload一下)。
当使用track_script时可以不用加nopreempt,只需要加上preempt_delay 5,这里的间隔时间要大于vrrp_script中定义的时长。
* preempt_delay master启动多久之后进行接管资源(VIP/Route信息等),并提是没有nopreempt选项。

——-virtual_server_group和virtual_server区域:virtual_server_group一般在超大型的LVS中用到,一般LVS用不过这东西,因此不多说。

virtual_server IP Port {
     delay_loop <INT>
     lb_algo rr|wrr|lc|wlc|lblc|sh|dh
     lb_kind NAT|DR|TUN
     persistence_timeout <INT>
     persistence_granularity <NETMASK>
     protocol TCP
     ha_suspend
     virtualhost <STRING>
     alpha
     omega
     quorum <INT>
     hysteresis <INT>
     quorum_up <STRING>|<QUOTED-STRING>
     quorum_down <STRING>|<QUOTED-STRING>
     sorry_server <IPADDR> <PORT>
     real_server <IPADDR> <PORT> {
         weight <INT>
         inhibit_on_failure
         notify_up <STRING>|<QUOTED-STRING>
         notify_down <STRING>|<QUOTED-STRING>
         # HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK
         HTTP_GET|SSL_GET {
             url {
                 path <STRING>
                 # Digest computed with genhash
                 digest <STRING>
                 status_code <INT>
             }
             connect_port <PORT>
             connect_timeout <INT>
             nb_get_retry <INT>
             delay_before_retry <INT>
         }
     }
 }
* delay_loop 延迟轮询时间(单位秒)。
* lb_algo 后端调试算法(load balancing algorithm)。
* lb_kind LVS调度类型NAT/DR/TUN。
* virtualhost 用来给HTTP_GET和SSL_GET配置请求header的。
* sorry_server 当所有real server宕掉时,sorry server顶替。
* real_server 真正提供服务的服务器。
* weight 权重。
* notify_up/down 当real server宕掉或启动时执行的脚本。
* 健康检查的方式,N多种方式。
* path 请求real serserver上的路径。
* digest/status_code 分别表示用genhash算出的结果和http状态码。
* connect_port 健康检查,如果端口通则认为服务器正常。
* connect_timeout,nb_get_retry,delay_before_retry分别表示超时时长、重试次数,下次重试的时间延迟

2.lvs:

–ipvs称之为IP虚拟服务器(IP Virtual Server,简写为IPVS)。是运行在LVS下的提供负载平衡功能的一种技术;

–IPVS的三种转发模式:根据负载均衡器转发客户端请求以及RS返回响应机制的不同,将IPVS的转发模式分为三种:NAT,DR,FULLNAT。(还有一种IP TUNNEL模式,IP通道技术,接触比较少)

——DR模式(Direct Routing):DR模式下,客户端的请求包到达负载均衡器的虚拟服务IP端口后,负载均衡器不会改写请求包的IP和端口,但是会改写请求包的MAC地址为后端RS的MAC地址,然后将数据包转发;真实服务器处理请求后,响应包直接回给客户端,不再经过负载均衡器。所以DR模式的转发效率是最高的,特别适合下行流量较大的业务场景,比如请求视频等大文件。

DR模式的特点:数据包在LB转发过程中,源/目的IP端口都不会变化LB只是将数据包的MAC地址改写为RS的MAC地址,然后转发给相应的RS。每台RS上都必须在环回网卡上绑定LB的虚拟服务IP,因为LB转发时并不会改写数据包的目的IP,所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包,而不是丢弃,必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP,自己是能够处理这个数据包的。否则RS会直接丢弃该数据包!RS上的业务进程必须监听在环回网卡的虚拟服务IP上,且端口必须和LB上的虚拟服务端口一致;因为LB不会改写数据包的目的端口,所以RS服务的监听端口必须和虚拟服务端口一致,否则RS会直接拒绝该数据包。RS处理完请求后,响应直接回给客户端,不再经过LB,因为RS收到的请求数据包的源IP是客户端的IP,所以理所当然RS的响应会直接回给客户端,而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。LB和RS须位于同一个子网,因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址,所以要能够查询到RS的MAC。而要获取到RS的MAC,则需要保证二者位于一个子网,否则LB只能获取到RS网关的MAC地址。

——NAT模式下,请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后,LB会对请求包做目的地址转换(DNAT),将请求包的目的IP改写为RS的IP。当收到RS的响应后,LB会对响应包做源地址转换(SNAT),将响应包的源IP改写为LB的IP。

NAT模式的特点:LB会修改数据包的地址,对于请求包,会进行DNAT;对于响应包,会进行SNAT。LB会透传客户端IP到RS(DR模式也会透传),虽然LB在转发过程中做了NAT转换,但是因为只是做了部分地址转发,所以RS收到的请求包里是能看到客户端IP的。需要将RS的默认网关地址配置为LB的浮动IP地址,因为RS收到的请求包源IP是客户端的IP,为了保证响应包在返回时能走到LB上面,所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然,如果客户端的IP是固定的,也可以在RS上添加明细路由指向LB的虚拟服务IP,不用改默认网关。LB和RS须位于同一个子网,并且客户端不能和LB/RS位于同一子网,因为需要将RS的默认网关配置为LB的虚拟服务IP地址,所以需要保证LB和RS位于同一子网。又因为需要保证RS的响应包能走回到LB上,则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC,响应包就直接回给客户端了,不会走网关,也就走不到LB上面了。这时候由于没有LB做SNAT,客户端收到的响应包源IP是RS的IP,而客户端的请求包目的IP是LB的虚拟服务IP,这时候客户端无法识别响应包,会直接丢弃。

–持久化连接:

9》lvs持久性连接
      对于电子商务网站来说,用户在挑选商品的时候使用的是80端口来浏览的,当付款的时候则是通过443的ssl加密的方式,当然当用户挑选完商品付款的时 候,我们当然不希望                https的443跳转到另外一台REAL SERVER上,很显然应该是同一REAL SERVER才对,这时候就要用到基于防火墙标记的持久连接,通过定义端口的姻亲关系来实现。在生产环                 境中用的最多的也是PNMP即基于防火墙标记的持久 连接,好了引子就说到这下面我们就来详细说说LVS的持久连接;  
    1>PPC(Persistent Port Connections):将来自于同一个客户端对同一个集群服务的请求,始终定向至此前选定的RS;(持久端口连接)
        例如:client---->LVS(80)---->RS1 或 client---->LVS(23)---->RS2
        缺陷:期望访问不同的端口到同一台RS上,无法实现。
        配置:
            ipvsadm -A -t 172.16.100.1:80 -s rr -p 3600
            ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.10 -g -w 2
            ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.11 -g -w 2
    2>PCC(Persistent Client Connections):将来自于同一个客户端对所有端口的请求,始终定向至此前选定的RS;(持久客户端连接)
        说明:PCC是一个虚拟服务没有端口号(或者端口号为0),以"-p" 来标识服务。
        缺陷:定向所有服务,期望访问不同的Real Server无法实现。
        配置:
          ipvsadm -A -t 172.16.100.1:0 -s rr -p 3600
          ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.10 -g -w 2
          ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.11 -g -w 2
    3>PNMPP(Persistent Netfilter Marked Packet Persistence):持久防火墙标记连接,根据iptables 的规则,将对于某类服务几个不同端口的访问定义为一                                                                                                                    类;
      先对某一特定类型的数据包打上标记,然后再将基于某一类标记的服务送到后台的 Real Server上去,后台的Real Server 并不识别这些标记。将持久和防             火墙标记结合起来就能够实现端口姻亲功能,只要是来自某一客户端的对某一特定服务(需要不同的端口)的访问都定义到同一台 Real Server上去。
    案例:一个用户在访问购物网站时同时使用HTTP(80)和HTTPS(443)两种协议,我们需要将其定义到同一台Real Server上,而其他的服务不受限制。
    配置:        
        iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 80 -j MARK --set-mark 8
        iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 443 -j MARK --set-mark 8
        ipvsadm -A -f 8 -s rr -p 600
        ipvsadm -a -f 8 -r 172.16.100.10 -g -w 2
        ipvsadm -a -f 8 -r 172.16.100.11 -g -w 1
     4>持久连接命令
      1.ipvsadm -A|E … -p timeout
      2.选项
      3.-p timeout 指定持久连接时长,默认为360秒,单位是秒,即6分钟
http://www.it165.net/admin/html/201307/1565.html

LVS+Keepalived+nginx部署文档.docx

##########nginx负载均衡策略#############

当后端是缓存服务器时,经常使用一致性哈希算法来进行负载均衡。
使用一致性哈希的好处在于,增减集群的缓存服务器时,只有少量的缓存会失效,回源量较小。
在nginx+ats / haproxy+squid等CDN架构中,nginx/haproxy所使用的负载均衡算法便是一致性哈希。
我们举个例子来说明一致性哈希的好处。
假设后端集群包含三台缓存服务器,A、B、C。
请求r1、r2落在A上。
请求r3、r4落在B上。
请求r5、r6落在C上。
使用一致性哈希时,当缓存服务器B宕机时,r1/r2会仍然落在A上,r5/r6会仍然落在C上
也就是说这两台服务器上的缓存都不会失效。r3/r4会被重新分配给A或者C,并产生回源。
使用其它算法,当缓存服务器B宕机时,r1/r2不再落在A上,r5/r6不再落在C上了。
也就是说A、B、C上的缓存都失效了,所有的请求都要回源。
这里不介绍一致性哈希算法的基本原理,如果不了解,先花个10分钟看下这篇文章:
http://www.codeproject.com/Articles/56138/Consistent-hashing
在分析模块代码之前,先来看下nginx所实现的一致性哈希算法。

原文:https://blog.csdn.net/zhangskd/article/details/50256111

#######################

Ubuntu系统安装注意事项:https://blog.csdn.net/fduffyyg/article/details/86648737

–https://www.2cto.com/kf/201804/738752.html

docker磁盘空间占满问题解决

(1)使用df -h查看发现磁盘空间占满了,由于该环境只部署了docker容器,因此首先查看容器占用空间情况:使用docker system df 查看发现container占用了91G的内存空间,及其异常;docker存储路径发现overlay2占用了61G;

–docker system df命令:

可以看到,docker system df 命令给出了images、containers、volumes、build cache占用磁盘的大小。最后一列RECLAIMABLE,表示可回收的空间大小。
使用docker  system df -v,可以显示更详细的信息:

–知道具体使用的存储空间后,可以使用docker system  prune来清理停掉的container、悬挂的image(没有tag)、没有使用的network、数据卷。

当然有个-a参数,可以清理所有的东西,包括没有使用的镜像(谨慎使用)。清理后如下,具体原因是一个镜像一直重启;

—使用docker system df查看结果如下,containers恢复正常水平;

####参考####楼主博文里还提供了脚本清理;

https://www.cnblogs.com/cuishuai/p/9629576.html

jmeter在mac上的使用

(1)JMeter的最新版本是5.0,JMeter 5.0需要Java 8、Java 9,所以我们最终选择的版本是:

* Java 8,下载地址历史版本下载地址

* JMeter 5.1,下载地址历史版本下载地址

(2)安装jdk:官网下载对应系统版本,安装完成后,进入终端查看下java -version(安装之前可先查看下,如果版本大于8,则不用安装)

(3)下载安装jmeter:有两种版本,二进制解压则可使用,源码需要自己编译,在此使用二进制版本;解压,使用终端进入./apache-jmeter-5.1.1/bin,执行命令sh jmeter启动,若没有报错,则可以直接使用;若报错找不到java环境,则需要下一步配置环境变量;

–配置Java环境变量:在根目录.bash_profile文件中添加:路径根据自己电脑进行配置,执行source ~/.bash_profile进行生效;

—我的电脑没有配置,也可以用;如果执行
如果你已经配置好了环境变量,在终端(Terminal)输入echo $JAVA_HOME,echo $PATH,echo $CLASSPATH,里面包含正确的JDK路径,那就可以跳过这一步。
* JAVA_HOME:指向JDK的安装目录;
* path:指定命令搜索路径,设置好path变量后,就可以在任何目录下执行javac/java等工具了;
* classpath:指定类搜索路径;

(4)优化:将jmeter程序路径添加到环境变量之中,以后启动直接输入jmeter即可;

export JMETER_HOME=/Users/roarlion/Documents/apache-jmeter-5.1.1
export PATH=.:$JMETER_HOME/bin:$PATH
export CLASSPATH=.:$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$JMETER_HOME/lib/logkit-2.0.jar

—将语言改为中文:

(5)基本使用,这里以mqtt协议测试为例:

安装mqtt插件:–https://github.com/emqx/mqtt-jmeter/releases下载最新版本jar包,放在$JMETER_HOME/lib/ext文件夹下;

—启动jmeter:点击Test plan右键,添加线程组,修改名称;

—在线程组右键添加取样器,选择mqtt connect;

—配置连接到服务器地址和端口,以及连接到协议;

–如果只是测试连接数,到此即可,如果需要发送包,则还需添加:MQTT Pub Sampler

—最后添加汇总报告,进行结果查看:

—如果采用双向ssl验证,需要指定相应的信任秘钥库(Trust Key Store), 客户端证书,以及对应的文件保护密码(Secret),可参考http://roarlion.cn/nginx%E9%85%8D%E7%BD%AEssl%E8%AF%81%E4%B9%A6/文档;

########报错########

(1)ERROR o.a.j.JMeter: Uncaught exception: java.lang.OutOfMemoryError:

JMeter不断出现“Out of Memory”错误,这通常是由压力测试中包含内存密集型监听器引起的。 可以通过编辑linux/windows的jmeter.sh/jmeter.bat文件来指示JVM使用更多内存。在这些文件中,找到一个为Heap设置值的部分:
例如设置:HEAP = -Xms256m -Xmx256m
可根据测试机器实际内存情况来更改这些值。 Xms表示jvm将采用的起始RAM,Xmx将是允许的最大值(对于HEAP)。

#######参考#######

https://www.jianshu.com/p/bce9077d883c

https://www.cnblogs.com/saryli/p/6928051.html

关于内存溢出:

http://www.mamicode.com/info-detail-2432023.html

dmidecode命令详解

1.简介:

*DMI (Desktop Management Interface,DMI)就是帮助收集电脑系统信息的管理系统,DMI信息的收集必须在严格遵照SMBIOS规范的前提下进行。 
*SMBIOS(SystemManagementBIOS)是主板或系统制造者以标准格式显示产品管理信息所需遵循的统一规范。
*SMBIOS和DMI是由行业指导机构DesktopManagement Task Force (DMTF)起草的开放性的技术标准,其中DMI设计适用于任何的平台和操作系统。
*DMI充当了管理工具和系统层之间接口的角色。它建立了标准的可管理系统更加方便了电脑厂商和用户对系统的了解。DMI的主要组成部分是ManagementInformation Format(MIF)数据库。这个数据库包括了所有有关电脑系统和配件的信息。通过DMI,用户可以获取序列号、电脑厂商、串口信息以及其它系统配件信息。
*Dmidecode 在主流的 Linux 发行版中都可以找到,只需通过所用发行版的包管理器安装即可,如sudo yum install dmidecode -y 
# dmidecode 3.0
Scanning /dev/mem for entry point.
SMBIOS 2.8 present.

Handle 0x0100, DMI type 1, 27 bytes
System Information
    Manufacturer: Dell Inc.
    Product Name: PowerEdge R430
    Version: Not Specified
    Serial Number: FZM2ZQ2
    UUID: 4C4C4544-005A-4D10-8032-C6C04F5A5132
    Wake-up Type: Power Switch
    SKU Number: SKU=NotProvided;ModelName=PowerEdge R430
    Family: Not Specified
--加粗行为记录头(recoce Header), 其中包括了:
recode id(handle): DMI表中的记录标识符,这是唯一的,比如上例中的Handle 0×0100。
dmi type id: 记录的类型,譬如说:BIOS,Memory,上例是type 1,即”System Information”
recode size: DMI表中对应记录的大小,上例为27bytes.(不包括文本信息,所有实际输出的内容比这个size要更大。)记录头之后就是记录的值
decoded values:记录值可以是多行的,比如上例显示了主板的制造商(manufacturer)、Product Name、version以及serialNumber。

2.作用:

dmidecode的作用是将DMI数据库中的信息解码,以可读的文本方式显示。由于DMI信息可以人为修改,因此里面的信息不一定是系统准确的信息。DMI被设计为一个能够在任何平台和操作系统下实现的接口规范,它允许操作人员在该数据区中手工添加一些BIOS不能探测到的诸如使用者姓名、销售商和计算机编号等额外的控制信息,因此我们也可以在不需要对BIOS进行操作的情况下使用DMI对MIFD数据库中的系统配置情况进行修改以适应不同环境下的系统要求。我们使用DMICFG修改BIOS;

3.使用方法:dmidecode

不带选项执行 dmidecode 通常会输出所有的硬件信息。Dmidecode 有个很有用的选项-t,可以按指定类型输出相关信息,假如要获得处理器方面的信息,则可以执行
dmidecode -t processor
查看服务器型号:dmidecode | grep 'Product Name'
查看主板的序列号:dmidecode |grep 'Serial Number'
查看系统序列号:dmidecode -s system-serial-number
查看内存信息:dmidecode -t memory
查看OEM信息:dmidecode -t 11

4.附录:dmidecode参数string及type列表

(1)Valid string keywords are:
bios-vendor
bios-version
bios-release-date
system-manufacturer
system-product-name
system-version
system-serial-number
system-uuid
baseboard-manufacturer
baseboard-product-name
baseboard-version
baseboard-serial-number
baseboard-asset-tag
chassis-manufacturer
chassis-type
chassis-version
chassis-serial-number
chassis-asset-tag
processor-family
processor-manufacturer
processor-version
processor-frequency
(2)Valid type keywords are:
bios
system
baseboard
chassis
processor
memory
Cache
connector
slot
(3)type全部编码列表
0 BIOS
1 System
2 Base Board
3 Chassis
4 Processor
5 Memory Controller
6 Memory Module
7 Cache
8 Port Connector
9 System Slots
10 On Board Devices
11 OEMStrings
12 System Configuration Options
13 BIOS Language
14 Group Associations
15 System Event Log
16 Physical Memory Array
17 Memory Device
18 32-bit Memory Error
19 Memory Array Mapped Address
20 Memory Device Mapped Address
21 Built-in Pointing Device
22 Portable Battery
23 System Reset
24 Hardware Security
25 System Power Controls
26 Voltage Probe
27 Cooling Device
28 Temperature Probe
29 Electrical Current Probe
30 Out-of-band Remote Access
31 Boot Integrity Services
32 System Boot
33 64-bit Memory Error
34 Management Device
35 Management Device Component
36 Management Device Threshold Data
37 Memory Channel
38 IPMI Device
39 Power Supply
40 Additional Information
41 Onboard Device

#############参考目录如下,再次表示感谢###############

https://www.cnblogs.com/dirt2/p/5830244.html

https://blog.csdn.net/legendmaker/article/details/10984009?utm_source=blogxgwz6

openstack安装配置

################################

#############

清除缓存:echo 3 > /proc/sys/vm/drop_caches

–开机自启动:

sudo systemctl disable httpd neutron-server.service neutron-linuxbridge-agent.service neutron-dhcp-agent.service neutron-metadata-agent.service openstack-nova-api.service openstack-nova-consoleauth.service openstack-nova-scheduler.service openstack-nova-conductor.service openstack-nova-novncproxy.service openstack-glance-api  openstack-glance-registry memcached rabbitmq-server.service mariadb

<span style="font-weight: bold;"–<重启network 服务,会扫描 /etc/sysconfig/network-scripts/ 目录下以 ifcfg-  开始的文件名,作为网卡配置文件,读取配置项,通过 ifup device boot 启动网卡

通过brctl 添加的网桥及接口,重启系统后,会被删除掉;

–网桥管理工具brctl:

一.安装
Centos系统
$ yum install bridge-utils
Ubuntu系统   
$ apt-get  install bridge-utils

二.使用
  1.添加网桥(br0)
   $ brctl addbr br0
注:设置br0可用
$ sudo ifconfig br0 192.168.100.1 netmask  255.255.255.0
2.查看网桥
  1)显示所有的网桥信息
       $ sudo brctl show
2)显示某个网桥(br0)的信息
      $ sudo brctl show br0
3.删除网桥(br0)
   $  sudo brctl delbr br0
---当网桥启动的时候是无法删除的,需要先把网卡停掉,ifconfig br0 down
4. 将eth0端口加入网桥br0
    $ brctl addif br0 eth0
5. 从网桥br0中删除eth0端口
    $ brctl delif br0 eth0

—-查看系统中网桥信息:

--执行删除操作:

—-TCP连接的几种状态:

TCP状态转移要点
    TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接,所以很有必要保证无用连接完全断开,否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中,最值得注意的状态有两个:CLOSE_WAIT和TIME_WAIT。

1、LISTENING状态
  FTP服务启动后首先处于侦听(LISTENING)状态。
2、ESTABLISHED状态
  ESTABLISHED的意思是建立连接。表示两台机器正在通信。
3、CLOSE_WAIT
    对方主动关闭连接或者网络异常导致连接中断,这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭
4、TIME_WAIT
    我方主动调用close()断开连接,收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期),以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放,所以作为服务器,在可能的情况下,尽量不要主动断开连接,以减少TIME_WAIT状态造成的资源浪费。
    目前有一种避免TIME_WAIT资源浪费的方法,就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的,在某些情况下这个操作可能会带来错误。

####################

1.OpenStack每个服务都有自己的CLI:

#¥执行命令之前,需要设置环境变量。这些变量包含用户名、Project、密码等;如果不设置,每次执行命令都必须设置相关的命令行参数

#¥各个服务的命令都有增、删、改、查的操作

其格式是

CMD <obj>-create [parm1] [parm2]…

CMD <obj>-delete [parm]

CMD <obj>-update [parm1] [parm2]…

CMD <obj>-list

CMD <obj>-show [parm]

例如 glance 管理的是 image,那么:

CMD 就是 glance;obj 就是 image,CMD 就是 neutron;obj 就是 net 和 subnet

有的命令 <obj> 可以省略,比如 nova

下面的操作都是针对 instance:nova boot,nova delete,nova list,nova show    

#$每个对象都有 ID

delete,show 等操作都以 ID 为参数,例如

#$ 可用 help 查看命令的用法

除了 delete,show 等操作只需要 ID 一个参数,其他操作可能需要更多的参数,用  help 查看所需的参数,格式是CMD help [SUB-CMD] ,例如查看 glance 都有哪些 SUB-CMD:查看 glance help image-update

2.设计 API 前端服务的好处在于: 1. 对外提供统一接口,隐藏实现细节 2. API 提供 REST 标准调用服务,便于与第三方系统集成 3. 可以通过运行多个 API 服务实例轻松实现 API 的高可用,比如运行多个 nova-api 进程

3.对于某项操作,如果有多个实体都能够完成任务,那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。比如Nova 有多个计算节点。 当需要创建虚机时,nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。

4.调度服务只管分配任务,真正执行任务的是 Worker 工作服务。比如在 Nova 中,这个 Worker 就是 nova-compute

5.Driver 框架,比如nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver

6.Messaging 服务,比如Messaging 是 nova-* 子服务交互的中枢,程序之间的调用通常分两种:同步调用和异步调用。

*同步调用:API 直接调用 Scheduler 的接口就是同步调用。其特点是 API 发出请求后需要一直等待,直到 Scheduler 完成对 Compute 的调度,将结果返回给 API 后 API 才能够继续做后面的工作。

*异步调用:API 通过 Messaging 间接调用 Scheduler 就是异步调用。其特点是 API 发出请求后不需要等待,直接返回,继续做后面的工作。Scheduler 从 Messaging 接收到请求后执行调度操作,完成后将结果也通过 Messaging 发送给 API。

在 OpenStack 这类分布式系统中,通常采用异步调用的方式,其好处是:
1. 解耦各子服务
2. 子服务不需要知道其他服务在哪里运行,只需要发送消息给 Messaging 就能完成调用。
3. 提高性能
4. 异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作,提高系统总的吞吐量。
5. 提高伸缩性
6. 子服务可以根据需要进行扩展,启动更多的实例处理更多的请求,在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务,也就是说变化对别人是透明的。

7.Database,OpenStack 各组件都需要维护自己的状态信息。比如 Nova 中有虚机的规格、状态,这些信息都是在数据库中维护的。

#####################tips##############################

1.kvm是为openstack进行创建虚拟机,如果openstack服务停用,可以使用libvirtd服务命令行进行管理。

2.虚拟化:系统虚拟化是将底层物理设备与上层操作系统,软件分离的一种去藕合技术,在一台物理集群上路径的划分出多台机器,虚拟化的目录表是实现IT 资源利用效率和灵活的最大化,产品vmware vsphere  esxi 就是最典型的产品

3.MQ 全称为 Message Queue, 消息队列( MQ)是一种应用程序对应用程序的通信方法,应用程序通过读写出入队列的消息(针对应用程序的数据)来通信,而无需专用连接来链接它们。Nginx(PHP)—》MQ—》MYSQL;消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋(秒杀或团抢)等问题,实现高性能,高可用,可伸缩和最终一致性架构。主流消息队列包括:ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等;(Openstack的架构决定了需要使用消息队列机制来实现不同模块间的通信,通过消息验证、消息转换、消息路由架构模式,带来的好处就是可以是模块之间最大程度解耦,客户端不需要关注服务端的位置和是否存在,只需通过消息队列进行信息的发送。RabbitMQ适合部署在一个拓扑灵活易扩展的规模化系统环境中,有效保证不同模块、不同节点、不同进程之间消息通信的时效性,可有效支持OpenStack云平台系统的规模化部署、弹性扩展、灵活架构以及信息安全的需求。

Rabbitmq消息测试如下,如上消息服务器部署完毕,可以进行简单消息的发布和订阅。Rabbitmq完整的消息通信包括:
* 发布者(producer)是发布消息的应用程序;
* 队列(queue)用于消息存储的缓冲;
* 消费者(consumer)是接收消息的应用程序。
RabbitMQ消息模型核心理念:发布者(producer)不会直接发送任何消息给队列,发布者(producer)甚至不知道消息是否已经被投递到队列,发布者(producer)只需要把消息发送给一个交换器(exchange),交换器非常简单,它一边从发布者方接收消息,一边把消息推入队列。
交换器必须知道如何处理它接收到的消息,是应该推送到指定的队列还是是多个队列,或者是直接忽略消息。

4.配置keystone:

--主要作用:
*管理用户及其权限
*维护 OpenStack Services 的 Endpoint
*Authentication(认证)和 Authorization(鉴权)

–主要名词理解:

--User 指代任何使用 OpenStack 的实体,可以是真正的用户,其他系统或者服务。Horizon 在 Identity->Users 管理 User,除了 admin 和 demo,OpenStack 也为 nova、cinder、glance、neutron 服务创建了相应的 User。 admin 也可以管理这些 User。
--Credentials 是 User 用来证明自己身份的信息,可以是: 1. 用户名/密码 2. Token 3. API Key 4. 其他高级方式
--Authentication 是 Keystone 验证 User 身份的过程。User 访问 OpenStack 时向 Keystone 提交用户名和密码形式的 Credentials,Keystone 验证通过后会给 User 签发一个 Token 作为后续访问的 Credential。
--Token 是由数字和字母组成的字符串,User 成功 Authentication 后由 Keystone 分配给 User。
1. Token 用做访问 Service 的 Credential
2. Service 会通过 Keystone 验证 Token 的有效性
3. Token 的有效期默认是 24 小时
--Project 用于将 OpenStack 的资源(计算、存储和网络)进行分组和隔离。 根据 OpenStack 服务的对象不同,Project 可以是一个客户(公有云,也叫租户)、部门或者项目组(私有云)。Horizon 在 Identity->Projects 中管理 Project,通过 Manage Members 将 User 添加到 Project 中
这里请注意:
1. 资源的所有权是属于 Project 的,而不是 User。
2. 在 OpenStack 的界面和文档中,Tenant / Project / Account 这几个术语是通用的,但长期看会倾向使用 Project
3. 每个 User(包括 admin)必须挂在 Project 里才能访问该 Project 的资源。 一个User可以属于多个 Project。
4. admin 相当于 root 用户,具有最高权限
--OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。
每个 Service 都会提供若干个 Endpoint,User 通过 Endpoint 访问资源和执行操作。
--Endpoint 是一个网络上可访问的地址,通常是一个 URL。 Service 通过 Endpoint 暴露自己的 API。 Keystone 负责管理和维护每个 Service 的 Endpoint。openstack catalog list可以查看URL信息;
--安全包含两部分:Authentication(认证)和 Authorization(鉴权) Authentication 解决的是“你是谁?”的问题 Authorization 解决的是“你能干什么?”的问题
Keystone 是借助 Role 来实现 Authorization 的:openstack role list可以进行查看;
*可以为 User 分配一个或多个 Role Horizon 的菜单为 Identity->Project->Manage Members,为user配置role;
*Service 决定每个 Role 能做什么事情 Service 通过各自的 policy.json 文件对 Role 进行访问控制。 下面是 Nova 服务 /etc/nova/policy.json 中的示例

上面配置的含义是:对于 create、attach_network 和 attach_volume 操作,任何Role的 User 都可以执行; 但只有 admin 这个 Role 的 User 才能执行 forced_host 操作。
OpenStack 默认配置只区分 admin 和非 admin Role。 如果需要对特定的 Role 进行授权,可以修改 policy.json。

每一个过程几乎都会涉及到上面的这些关系,以访问images为例;19;

OpenStack排查日志主要都是通过日志,每个service都有自己的日志,Keystone 主要有两个日志:keystone.log 和 keystone_access.log,保存在 /var/log/httpd/ 目录里。日志等级在/etc/keystone/keystone.conf进行配置;

5.配置glance镜像服务:

—在 OpenStack 中,提供 Image Service 的是 Glance,其具体功能如下:

1. 提供 REST API 让用户能够查询和获取 image 的元数据和 image 本身

2. 支持多种方式存储 image,包括普通的文件系统、Swift、Amazon S3 等

3. 对 Instance 执行 Snapshot 创建新的 image

glance-api 是系统后台运行的服务进程。 对外提供 REST API,响应 image 查询、获取和存储的调用。
---glance-api 不会真正处理请求。 如果是与 image metadata(元数据)相关的操作,glance-api 会把请求转发给 glance-registry;
---如果是与 image 自身存取相关的操作,glance-api 会把请求转发给该 image 的 store backend。

glance-registry 是系统后台运行的服务进程。 负责处理和存取 image 的 metadata,例如 image 的大小和类型。

glance-store:image 的元数据 通过glance-registry 存放在 db 中; image 的chunk 数据 通过 glance-store 存放在各种 backend store 中,并从中获取
支持多种方式存储 image,包括普通的文件系统、Swift、Amazon S3、GlusterFS 等

registry在api后面,它的作用和mysql打交道,存储镜像的属性registry监听9191端口,glance-api监听9292端口
配置glance服务,要配置2个配置文件,1个api和1个registry
glance不需要配置消息队列,但是需要配置keystone
镜像默认在下面路径下,这个目录是 /var/lib/glance/images/。日志文件也在/var/log/glance目录下;

–glance支持多种格式的image:Image 的 metadata 会保持到 database 中,默认是 MySQL。

Store backend
Glance 自己并不存储 image。真正的 image 是存放在 backend 中的。Glance 支持多种 backend,包括
1. A directory on a local file system(这是默认配置)
2. GridFS
3. Ceph RBD
4. Amazon S3
5. Sheepdog
6. OpenStack Block Storage (Cinder)
7. OpenStack Object Storage (Swift)
8. VMware ESX
具体使用哪种 backend,是在 /etc/glance/glance-api.conf 中配置的
在我们的 devstack 环境中,image 存放在控制节点本地目录 filesystem_store_datadir = /var/lib/glance/images,每个 image 在目录下都对应有一个文件,文件以 image 的 ID 命名
镜像创建可以在web前端进行操作,也可以在命令行执行 image 创建命令
glance image-create --name cirros --file /tmp/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --progress(可以显示进度)
openstack image create "cirros" --file cirros-0.3.5-x86_64-disk.img --disk-format qcow2 --container-format bare --public

6.nova配置:

—-维护和管理云环境的计算资源

—-虚拟机生命周期管理

#############Nova 通过 Message Queue 作为子服务的信息中转站,OpenStack 默认是用 RabbitMQ 作为 Message Queue##############
@API:nova-api
接收和响应客户的 API 调用。
除了提供 OpenStack 自己的API,nova-api 还支持 Amazon EC2 API。
@Compute Core
nova-scheduler:虚机调度服务,负责决定在哪个计算节点上运行虚机
nova-compute:管理虚机的核心服务,通过调用 Hypervisor API 实现虚机生命周期管理
Hypervisor:计算节点上跑的虚拟化管理程序,虚机管理最底层的程序。不同虚拟化技术提供自己的 Hypervisor。常用的 Hypervisor 有 KVM,Xen, VMWare 等
@nova-conductor
nova-compute 经常需要更新数据库,比如更新虚机的状态。出于安全性和伸缩性的考虑,nova-compute 并不会直接访问数据库,而是将这个任务委托给 nova-conductor;安全性主要是compute安装在计算节点上,直接访问数据库不安全;伸缩性,可以由多个comductor进行处理,充分解耦;
@Console Interface
nova-console:用户可以通过多种方式访问虚机的控制台:
nova-novncproxy,基于 Web 浏览器的 VNC 访问;nova-spicehtml5proxy,基于 HTML5 浏览器的 SPICE 访问;nova-xvpnvncproxy,基于 Java 客户端的 VNC 访问
nova-consoleauth:负责对访问虚机控制台请求提供 Token 认证
nova-cert:提供 x509 证书支持
Database:Nova 会有一些数据需要存放到数据库中,一般使用 MySQL。数据库安装在控制节点上。Nova 使用命名为 “nova” 的数据库。

—OpenStack 将这些需求定义在 flavor 中,用户只需要指定用哪个 flavor 就可以了。(一个flavor就是一个示例)

—Flavor 主要定义了 VCPU,RAM,DISK 和 Metadata 这四类。 nova-scheduler 会按照 flavor 去选择合适的计算节点。

—在/etc/nova/nova.conf 中,nova 通过 scheduler_driver,scheduler_available_filters 和 scheduler_default_filters 这三个参数来配置 nova-scheduler。

—Filter scheduler 是 nova-scheduler 默认的调度器,调度过程分为两步:

1. 通过过滤器(filter)选择满足条件的计算节点(运行 nova-compute)
2. 通过权重计算(weighting)选择在最优(权重值最大)的计算节点上创建 Instance。
scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
Nova 允许使用第三方 scheduler,配置 scheduler_driver 即可。
当 Filter scheduler 需要执行调度操作时,会让 filter 对计算节点进行判断,filter 返回 True 或 False。
Nova.conf 中的 scheduler_available_filters 选项用于配置 scheduler 可用的 filter,默认是所有 nova 自带的 filter 都可以用于滤操作。
scheduler_available_filters = nova.scheduler.filters.all_filters
另外还有一个选项 scheduler_default_filters,用于指定 scheduler 真正使用的 filter,默认值如下
scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter
Filter scheduler 将按照列表中的顺序依次过滤。
RetryFilter
RetryFilter 的作用是刷掉之前已经调度过的节点。
举个例子方便大家理解: 假设 A,B,C 三个节点都通过了过滤,最终 A 因为权重值最大被选中执行操作。 但由于某个原因,操作在 A 上失败了。 默认情况下,nova-scheduler 会重新执行过滤操作(重复次数由 scheduler_max_attempts 选项指定,默认是 3)。 那么这时候 RetryFilter 就会将 A 直接刷掉,避免操作再次失败。 RetryFilter 通常作为第一个 filter。
AvailabilityZoneFilter
为提高容灾性和提供隔离服务,可以将计算节点划分到不同的Availability Zone中。
例如把一个机架上的机器划分在一个 Availability Zone 中。 OpenStack 默认有一个命名为 “Nova” 的 Availability Zone,所有的计算节点初始都是放在 “Nova” 中。 用户可以根据需要创建自己的 Availability Zone。
RamFilter 将不能满足 flavor 内存需求的计算节点过滤掉。为了提高系统的资源使用率,OpenStack 在计算节点可用内存时允许 overcommit,也就是可以超过实际内存大小。 超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的,默认值为 1.5
DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤掉。Disk 同样允许 overcommit,通过 nova.conf 中 disk_allocation_ratio 控制,默认值为 1
CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。vCPU 同样允许 overcommit,通过 nova.conf 中 cpu_allocation_ratio 控制,默认值为 16
ComputeFilter 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。
ComputeCapabilitiesFilter 根据计算节点的特性来筛选。例如我们的节点有 x86_64 和 ARM 架构的,如果想将 Instance 指定部署到 x86_64 架构的节点上,就可以利用到 ComputeCapabilitiesFilter。还记得 flavor 中有个 Metadata 吗,Compute 的 Capabilitie s就在 Metadata中 指定.如果没有设置 Metadata,ComputeCapabilitiesFilter 不会起作用
ImagePropertiesFilter 根据所选 image 的属性来筛选匹配的计算节点。跟 flavor 类似,image 也有 metadata,用于指定其属性。
ServerGroupAntiAffinityFilter 可以尽量将 Instance 分散部署到不同的节点上。
ServerGroupAffinityFilter与 ServerGroupAntiAffinityFilter 的作用相反,ServerGroupAffinityFilter 会尽量将 instance 部署到同一个计算节点上。
Weight目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值:空闲内存越多,权重越大,instance 将被部署到当前空闲内存最多的计算节点上。
日志记录在/var/log/nova目录下,注:要显示 DEBUG 日志,需要在 /etc/nova/nova.conf 中打开 debug 选项
[DEFAULT]
debug = True
nova-scheduler

1. 最开始有 6 个计算节点 Host1-Host6
2. 通过多个 filter 层层过滤,Host2 和 Host4 没有通过,被刷掉了
Host1,Host3,Host5,Host6 计算权重,结果 Host5 得分最高,最终入选

####################实例:创建主机流程###################

1. 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送请求:“帮我创建一个虚机”
2. API 对请求做一些必要处理后,向 Messaging(RabbitMQ)发送了一条消息:“让 Scheduler 创建一个虚机”
3. Scheduler(nova-scheduler)从 Messaging 获取到 API 发给它的消息,然后执行调度算法,从若干计算节点中选出节点 A
4. Scheduler 向 Messaging 发送了一条消息:“在计算节点 A 上创建这个虚机”
5. 计算节点 A 的 Compute(nova-compute)从 Messaging 中获取到 Scheduler 发给它的消息,然后在本节点的 Hypervisor 上启动虚机。
在虚机创建的过程中,Compute 如果需要查询或更新数据库信息,会通过 Messaging 向 Conductor(nova-conductor)发送消息,Conductor 负责数据库访问。

对于 Nova,这些服务会部署在两类节点上:计算节点和控制节点。 计算节点上安装了 Hypervisor,上面运行虚拟机。 由此可知: 1. 只有 nova-compute 需要放在计算节点上。 2. 其他子服务则是放在控制节点上的。 nova service-list可以查看具体的服务分布;

nova-compute 在计算节点上运行,负责管理节点上的 instance。
OpenStack 对 instance 的操作,最后都是交给 nova-compute 来完成的。
nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。对于众多的hypervisor,nova-compute 为这些 Hypervisor 定义了统一的接口,Hypervisor 只需要实现这些接口,就可以 Driver 的形式即插即用到 OpenStack 系统中。nova-compute 为这些 Hypervisor 定义了统一的接口,Hypervisor 只需要实现这些接口,就可以 Driver 的形式即插即用到 OpenStack 系统中。
nova-compute 的功能可以分为两类:
1. 定时向 OpenStack 报告计算节点的状态:nova-compute 可以通过 Hypervisor 的 driver 拿到这些信息。举例来说,在我们的实验环境下 Hypervisor 是 KVM,用的 Driver 是 LibvirtDriver。LibvirtDriver 可以调用相关的 API 获得资源信息,这些 API 的作用相当于我们在 CLI 里执行 virsh nodeinfo、virsh dominfo 等命令。
2. 实现 instance 生命周期的管理,包括 instance 的 launch、shutdown、reboot、suspend、resume、terminate、resize、migration、snapshot 等。
*launch:nova-compute 创建 instance 的过程可以分为 4 步:
1. 为 instance 准备资源,根据flavor模板进行分配,网络资源等;
2. 创建 instance 的镜像文件
--首先将该 image 下载到计算节点(初次下载)
--然后将其作为 backing file 创建 instance 的镜像文件。
3. 创建 instance 的 XML 定义文件
4. 创建虚拟网络并启动虚拟机
易混点之镜像和镜像文件:
*1. image,指的是 Glance 上保存的镜像,作为 instance 运行的模板。 计算节点将下载的 image 存放在 /opt/stack/data/nova/instances/_base 目录下。
2. 镜像文件,指的是 instance 启动盘所对应的文件
3. 二者的关系是:image 是镜像文件 的 backing file。image 不会变,而镜像文件会发生变化。比如安装新的软件后,镜像文件会变大。
因为英文中两者都叫 “image”,为避免混淆,我们用 “image” 和 “镜像文件” 作区分。

!生命周期管理:

***soft reboot 与 hard reboot 的区别在于:
1.  soft reboot 只是重启操作系统,整个过程中,instance 依然处于运行状态。相当于在 linux 中执行 reboot 命令
2.  hard reboot 是重启 instance,相当于关机之后再开机
***Lock/Unlock:为了避免误操作,比如意外重启或删除 instance,可以将 instance  加锁。对被加锁(Lock)的 instance 执行重启等改变状态的操作会提示操作不允许。执行解锁(Unlock)操作后恢复正常。Lock/Unlock 操作都是在 nova-api 中进行的。操作成功后 nova-api 会更新 instance 加锁的状态。执行其他操作时,nova-api 根据加锁状态来判断是否允许。(admin不受lock影响,任何人都可以unlock)
***有时需要短时间暂停 instance,可以通过 Pause 操作将 instance 的状态保存到宿主机的内存中。当需要恢复的时候,执行 Resume 操作,从内存中读回 instance 的状态,然后继续运行 instance。
***pause和suspend区别:
相同点:两者都是暂停 instance 的运行,并保存当前状态,之后可以通过 Resume 操作恢复
不同点:
1.  Suspend 将 instance 的状态保存在磁盘上;Pause 是保存在内存中,所以 Resume 被 Pause 的 instance 要比 Suspend 快。
2.  Suspend 之后的 instance,其状态是 Shut Down;而被 Pause 的 instance 状态是Paused。
3.  虽然都是通过 Resume 操作恢复,Pause 对应的 Resume 在 OpenStack 内部被叫作 “Unpause”;Suspend 对应的 Resume 才是真正的 “Resume”。这个在日志中能体现出来。
Suspend/Resume 的日志分析留给大家做练习。

8.Neutron:软件定义网络(software-defined networking, SDN)”所具有的灵活性和自动化优势使其成为云时代网络管理的主流。Neutron 的设计目标是实现“网络即服务(Networking as a Service)”。Neutron 为整个 OpenStack 环境提供网络支持,包括二层交换,三层路由,负载均衡,防火墙和 VPN 等。Neutron 提供了一个灵活的框架,通过配置,无论是开源还是商业软件都可以被用来实现这些功能。

***二层交换 Switching:Nova 的 Instance 是通过虚拟交换机连接到虚拟二层网络的;Neutron 支持多种虚拟交换机,包括 Linux 原生的 Linux Bridge 和 Open vSwitch。
***三层路由 Routing:Instance 可以配置不同网段的 IP,Neutron 的 router(虚拟路由器)实现 instance 跨网段通信。router 通过 IP forwarding,iptables 等技术来实现路由和 NAT。
***负载均衡 Load Balancing:Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service(LBaaS),提供了将负载分发到多个 instance 的能力。支持多种plugins,目前默认的 Plugin 是 HAProxy
***防火墙 Firewalling:Neutron 通过下面两种方式来保障 instance 和网络的安全性。Security Group通过 iptables 限制进出 instance 的网络包。Firewall-as-a-Service(FWaaS)限制进出虚拟路由器的网络包,也是通过 iptables 实现。

Neutron 由如下组件构成:
Neutron Server
对外提供 OpenStack 网络 API,接收请求,并调用 Plugin 处理请求。
Plugin
处理 Neutron Server 发来的请求,维护 OpenStack 逻辑网络的状态, 并调用 Agent 处理请求。
Agent
处理 Plugin 的请求,负责在 network provider 上真正实现各种网络功能。
network provider
提供网络服务的虚拟或物理网络设备,例如 Linux Bridge,Open vSwitch 或者其他支持 Neutron 的物理交换机。
Queue
Neutron Server,Plugin 和 Agent 之间通过 Messaging Queue 通信和调用。
Database
存放 OpenStack 的网络状态信息,包括 Network, Subnet, Port, Router 等。
!!!plugin 解决的是 What 的问题,即网络要配置成什么样子?而至于如何配置 How 的工作则交由 agent 完成。plugin,agent 和 network provider 是配套使用的,plugin 的一个主要的职责是在数据库中维护 Neutron 网络的状态信息,plugin 按照功能分为两类: core plugin 和 service plugin。core plugin 维护 Neutron 的 netowrk, subnet 和 port 相关资源的信息,与 core plugin 对应的 agent 包括 linux bridge, OVS 等; service plugin 提供 routing, firewall, load balance 等服务,也有相应的 agent。

—部署实践:

方案1:控制节点 + 计算节点
在这个部署方案中,OpenStack 由控制节点和计算节点组成。
控制节点:部署的服务包括:neutron server, core plugin 的 agent 和 service plugin 的 agent。
计算节点:部署 core plugin 的agent,负责提供二层网络功能。
1. core plugin 和 service plugin 已经集成到 neutron server,不需要运行独立的 plugin 服务。
2. 控制节点和计算节点都需要部署 core plugin 的 agent,因为通过该 agent 控制节点与计算节点才能建立二层连接。
3. 可以部署多个控制节点和计算节点。
方案2:控制节点 + 网络节点 + 计算节点
在这个部署方案中,OpenStack 由控制节点,网络节点和计算节点组成。
控制节点:部署 neutron server 服务。
网络节点:部署的服务包括:core plugin 的 agent 和 service plugin 的 agent。
计算节点:部署 core plugin 的agent,负责提供二层网络功能。
这个方案的要点是将所有的 agent 从控制节点分离出来,部署到独立的网络节点上。
1. 控制节点只负责通过 neutron server 响应 API 请求。
2. 由独立的网络节点实现数据的交换,路由以及 load balance等高级网络服务。
3. 可以通过增加网络节点承担更大的负载。
4. 可以部署多个控制节点、网络节点和计算节点。
该方案特别适合规模较大的 OpenStack 环境。

(1)Neutron Server:

Core API
对外提供管理 network, subnet 和 port 的 RESTful API。
Extension API
对外提供管理 router, load balance, firewall 等资源 的 RESTful API。
Commnon Service
认证和校验 API 请求。
Neutron Core
Neutron server 的核心处理程序,通过调用相应的 Plugin 处理请求。
Core Plugin API
定义了 Core Plgin 的抽象功能集合,Neutron Core 通过该 API 调用相应的 Core Plgin。
Extension Plugin API
定义了 Service Plgin 的抽象功能集合,Neutron Core 通过该 API 调用相应的 Service Plgin
Core Plugin
实现了 Core Plugin API,在数据库中维护 network, subnet 和 port 的状态,并负责调用相应的 agent 在 network provider 上执行相关操作,比如创建 network。
Service Plugin
实现了 Extension Plugin API,在数据库中维护 router, load balance, security group 等资源的状态,并负责调用相应的 agent 在 network provider 上执行相关操作,比如创建 router。

–归纳起来,Neutron Server 包括两部分:1. 提供 API 服务。2. 运行 Plugin。即Neutron Server = API + Plugins

—Moduler Layer 2(ML2)是 Neutron 在 Havana 版本实现的一个新的 core plugin,用于替代原有的 linux bridge plugin 和 open vswitch plugin。允许在 OpenStack 网络中同时使用多种 Layer 2 网络技术,不同的节点可以使用不同的网络实现机制。 ML2 不但支持异构部署方案,同时能够与现有的 agent 无缝集成:以前用的 agent 不需要变,只需要将 Neutron server 上的传统 core plugin 替换为 ML2。同时要支持新的 network provider 就变得简单多了:无需从头开发 core plugin,只需要开发相应的 mechanism driver,大大减少了要编写和维护的代码。

—ML2 对二层网络进行抽象和建模,引入了 type driver 和 mechanism driver。这两类 driver 解耦了 Neutron 所支持的网络类型(type)与访问这些网络类型的机制(mechanism)

Type Driver
Neutron 支持的每一种网络类型都有一个对应的 ML2 type driver。 type driver 负责维护网络类型的状态,执行验证,创建网络等。 ML2 支持的网络类型包括 local, flat, vlan, vxlan 和 gre。 我们将在后面章节详细讨论每种 type。
Mechanism Driver
Neutron 支持的每一种网络机制都有一个对应的 ML2 mechanism driver。 mechanism driver 负责获取由 type driver 维护的网络状态,并确保在相应的网络设备(物理或虚拟)上正确实现这些状态。

--mechanism driver 有三种类型:
Agent-based
包括 linux bridge, open vswitch 等。
Controller-based
包括 OpenDaylight, VMWare NSX 等。
基于物理交换机
包括 Cisco Nexus, Arista, Mellanox 等。

—Core Plugin/Agent 负责管理核心实体:net, subnet 和 port。而对于更高级的网络服务,则由 Service Plugin/Agent 管理。Service Plugin 及其 Agent 提供更丰富的扩展功能,包括路由,load balance,firewall等,如图所示:

DHCP
dhcp agent 通过 dnsmasq 为 instance 提供 dhcp 服务。
Routing
l3 agent 可以为 project(租户)创建 router,提供 Neutron subnet 之间的路由服务。路由功能默认通过 IPtables 实现。
Firewall
l3 agent 可以在 router 上配置防火墙策略,提供网络安全防护。
另一个与安全相关的功能是 Security Group,也是通过 IPtables 实现。
Firewall 与 Security Group 的区别在于:
1. Firewall 安全策略位于 router,保护的是某个 project 的所有 network。
2. Security Group 安全策略位于 instance,保护的是单个 instance。
Firewall 与 Security Group 后面会详细分析。
Load Balance
Neutron 默认通过 HAProxy 为 project 中的多个 instance 提供 load balance 服务。

!!!总结:

与 OpenStack 其他服务一样,Neutron 采用的是分布式架构,包括 Neutorn Server、各种 plugin/agent、database 和 message queue。
1. Neutron server 接收 api 请求。
2. plugin/agent 实现请求。
3. database 保存 neutron 网络状态。
4. message queue 实现组件之间通信。
metadata-agent 之前没有讲到,这里做个补充:
instance 在启动时需要访问 nova-metadata-api 服务获取 metadata 和 userdata,这些 data 是该 instance 的定制化信息,比如 hostname, ip, public key 等。
但 instance 启动时并没有 ip,如何能够通过网络访问到 nova-metadata-api 服务呢?
答案就是 neutron-metadata-agent
该 agent 让 instance 能够通过 dhcp-agent 或者 l3-agent 与 nova-metadata-api 通信

1. Neutron 通过 plugin 和 agent 提供的网络服务。
2. plugin 位于 Neutron server,包括 core plugin 和 service plugin。
3. agent 位于各个节点,负责实现网络服务。
4. core plugin 提供 L2 功能,ML2 是推荐的 plugin。
5. 使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。
service plugin 和 agent 提供扩展功能,包括 dhcp, routing, load balance, firewall, vpn 等。
OpenStack 至少包含下面几类网络流量:
Management 网络用于节点之间 message queue 内部通信以及访问 database 服务,所有的节点都需要连接到 management 网络。
API 网络OpenStack 各组件通过该网络向用户暴露 API 服务。Keystone, Nova, Neutron, Glance, Cinder, Horizon 的 endpoints 均配置在 API 网络上。通常,管理员也通过 API 网络 SSH 管理各个节点。
VM 网络VM 网络也叫 tenant 网络,用于 instance 之间通信。VM 网络可以选择的类型包括 local, flat, vlan, vxlan 和 gre。VM 网络由 Neutron 配置和管理。
External 网络External 网络指的是 VM 网络之外的网络,该网络不由 Neutron 管理。Neutron 可以将 router attach 到 External 网络,为 instance 提供访问外部网络的能力。External 网络可能是企业的 intranet,也可能是 internet。

9.存储:

####操作系统获得存储空间的方式一般有两种:
1. 通过某种协议(SAS,SCSI,SAN,iSCSI 等)挂接裸硬盘,然后分区、格式化、创建文件系统;或者直接使用裸硬盘存储数据(数据库)
2. 通过 NFS、CIFS 等 协议,mount 远程的文件系统
第一种裸硬盘的方式叫做 Block Storage(块存储),每个裸硬盘通常也称作 Volume(卷) 第二种叫做文件系统存储。NAS 和 NFS 服务器,以及各种分布式文件系统提供的都是这种存储。
###Block Storage Servicet 提供对 volume 从创建到删除整个生命周期的管理。从 instance 的角度看,挂载的每一个 Volume 都是一块硬盘。OpenStack 提供 Block Storage Service 的是 Cinder,其具体功能是:
1. 提供 REST API 使用户能够查询和管理 volume、volume snapshot 以及 volume type
2. 提供 scheduler 调度 volume 创建请求,合理优化存储资源的分配
3. 通过 driver 架构支持多种 back-end(后端)存储方式,包括 LVM,NFS,Ceph 和其他诸如 EMC、IBM 等商业存储产品和方案

Cinder 包含如下几个组件:
cinder-api
接收 API 请求,调用 cinder-volume 执行操作。
cinder-volume
管理 volume 的服务,与 volume provider 协调工作,管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。
cinder-scheduler
scheduler 通过调度算法选择最合适的存储节点创建 volume。
volume provider
数据的存储设备,为 volume 提供物理存储空间。
cinder-volume 支持多种 volume provider,每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。
Message Queue
Cinder 各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列,子服务之间实现了解耦,这种松散的结构也是分布式系统的重要特征。
Database   Cinder 有一些数据需要存放到数据库中,一般使用 MySQL。数据库是安装在控制节点上的,比如在我们的实验环境中,可以访问名称为“cinder”的数据库。

10.日志学习:

日志的格式
OpenStack 的日志格式都是统一的,如下
<时间戳><日志等级><代码模块><Request ID><日志内容><源代码位置>
简单说明一下
时间戳     日志记录的时间,包括 年 月 日 时 分 秒 毫秒
日志等级       有INFO WARNING ERROR DEBUG等
代码模块       当前运行的模块Request ID  日志会记录连续不同的操作,为了便于区分和增加可读性,每个操作都被分配唯一的Request ID,便于查找
日志内容       这是日志的主体,记录当前正在执行的操作和结果等重要信息
源代码位置 日志代码的位置,包括方法名称,源代码文件的目录位置和行号。这一项不是所有日志都有

11.创建虚拟机,注入初始密码:https://blog.csdn.net/zss131456/article/details/84837997

–centos镜像:http://cloud.centos.org/centos/7/images/

–Ubuntu镜像:http://cloud-images.ubuntu.com/trusty/current/

centos7:

#!/bin/sh
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config
systemctl restart sshd
passwd root<<EOF
123123
123123
EOF
--centos6.6
#!/bin/sh  
sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/g' /etc/ssh/sshd_config  
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config  
cp -f /home/centos/.ssh/authorized_keys /root/.ssh/  
service sshd restart  
passwd centos<<EOF  
123456
123456
EOF

–ubuntu:下载qcw2镜像即可,amd类型;

#!/bin/sh  
sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/g' /etc/ssh/sshd_config  
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config  
cp -f /home/ubuntu/.ssh/authorized_keys /root/.ssh/  
service ssh restart  
passwd ubuntu<<EOF  
123456
123456
EOF

1.ifconfig命令没有找到,这是由于我们采用mini安装,只要装net-tools即可:yum -y install net-tools

2.su -s /sudo -s 

-c command 或 --command=command 变更为帐号为 USER 的使用者并执行指令(command)后再变回原来使用者
-s shell 或 --shell=shell 指定要执行的 shell (bash csh tcsh 等),预设值为 /etc/passwd 内的该使用者(USER) shell
sed -i 就是直接对文本文件进行操作的
sed -i 's/原字符串/新字符串/' /home/1.txt
sed -i 's/原字符串/新字符串/g' /home/1.txt
去掉 “行首” 带“@”的首字母@
sed -i 's/^@//' file
特定字符串的行前插入新行
sed -i '/特定字符串/i 新行字符串' file
特定字符串的行后插入新行
sed -i '/特定字符串/a 新行字符串' file
特定字符串的删除
sed -i '/字符串/d' file

3.error: Found option without preceding group in config file: /etc/my.cnf.d/client.cnf at line: 3

–错误:在配置文件中没有前面的组发现选项,很明显由配置项没有被涵盖在某个组下面;

4.You are not authorized to perform the requested action: identity:create_project. (HTTP 403) (Request-ID: req-227a117a-29c5-40fb-9c14-10718836fe01)

–重新source sh认证文件,获得token即可:openstack token issue

5.openstack-glance-api启动了,但是9292端口没有起来;看日志啊啊啊啊 啊啊啊啊啊啊啊啊

—错误原因:其实一开始就发现日志的权限不对,但是想当然了;从系统日志messages中也可以看到日志权限的问题;浪费了时间;

6.devstack安装报错收集:

遇到问题
解决方案
pip install pyldap 报错:lber.h:没有那个文件或目录
yum install openldap-devel
Could not install packages due to an EnvironmentError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Max retries exceeded with url: /packages/60/8e/cdcc5c8c97dc4d591dc96b6f452f31393fc1393bd1f37d2819bcce9d0d57/ChatterBot-0.8.7-py2.py3-none-any.whl (Caused by NewConnectionError('<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7fef59884950>: Failed to establish a new connection: [Errno -3]
DNS配置问题:
sudo vim /etc/resolv.conf #打开DNS编辑器 **在打开的编辑器的最下方,补充以下内容** 
nameserver 8.8.8.8 #DNS 
nameserver 114.114.114.114 #DNS2
error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib64/libvirt/storag  e-backend/libvirt_storage_backend_rbd.so': /usr/lib64/libvirt/storage-backend/libvirt_storage_backend_rbd.so: undefined symbol: rbd_diff_iterate2 。
缺失的链接库文件在librbd1包里,解决方法如下:
1. yum update librbd1
2. systemctl restart libvirtd
ReadTimeoutError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out.
解决方法,设置超时时间
pip –default-timeout=100 install -U Pillow
./stack.sh: line 488: generate-subunit: command not found
sudo yum install -y python-pip
sudo pip install –upgrade pip
sudo pip install -U os-testr
Cannot uninstall 'urllib3'. It is a distutils installed project and thus we cannot accurately determ
此类问题只要  sudo pip install –ignore-installed +模块名  强制升级下
                            例:sudo pip install –ignore-installed urllib3
yum安装软件报错:curl#6 – "Could not resolve host: mirrorlist.centos.org; Temporary failure in name resolut
dns解析的问题,处理办法:
vim /etc/resolv.conf  加入:
nameserver 8.8.8.8
nameserver 8.8.4.4
search localdomain
启动sshd时,报“Could not load host key”错
生成以下三种秘钥文件:
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

疑问:

1.为什么消息队列耗时少:已解决;

--将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。以上三个任务全部完成后,返回给客户端,总共花费时间为150MS。引入消息队列后,将不是必须的业务逻辑,异步处理

--用户的响应时间相当于是注册信息写入数据库的时间,50毫秒。注册邮件,发送短信写入消息队列后,直接返回,因此写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒(这边的意思应该是信息写入数据库之后,直接返回响应给用户,不用等待邮件和短信发送完毕;原先通过同步处理,引入消息队列变成异步处理;)

2.创建用户这步是否需要root权限:

[junoN1@node1 ~]$ source admin-openstack.sh
[junoN1@node1 ~]$ openstack token issue
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field      | Value                                                                                                                                                                                   |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| expires    | 2019-01-23T06:50:19+0000                                                                                                                                                                |
| id         | gAAAAABcSACbADiaXO2b4AGZuk9Rmsiu0_4Yp814NWtNRX7pGmWFKXTOmxC1HPjs4OKMbhILCw_bjbNPGhUwchRLZutNboxBDQERHLfOZY9HmXTjrRyJStd9j6_ITuoPu5kFZnctaOY_17GrStOehSklNiUiIlEm7M40X-1qGgLxroK0SDKdbzQ |
| project_id | 4bde9c33b2de4dbcab0b51b83e066ea8                                                                                                                                                        |
| user_id    | d5e9a83c7f28429f9111c382a4effd48                                                                                                                                                        |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
[junoN1@node1 ~]$ sudo openstack project create --domain default --description "Demo Project" demo
Missing value auth-url required for auth plugin password
[junoN1@node1 ~]$ openstack project create --domain default --description "Demo Project" demo
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | Demo Project                     |
| domain_id   | default                          |
| enabled     | True                             |
| id          | 7598c8f2350a4b4ca25734473c294843 |
| is_domain   | False                            |
| name        | demo                             |
| parent_id   | default                          |
+-------------+----------------------------------+
[junoN1@node1 ~]$ openstack user create --domain default --password=demo demo
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | da38f6e1f0294c368711081056506477 |
| name                | demo                             |
| options             | {}                               |
| password_expires_at | None                             |
+---------------------+----------------------------------+
[junoN1@node1 ~]$ openstack role create user
+-----------+----------------------------------+
| Field     | Value                            |
+-----------+----------------------------------+
| domain_id | None                             |
| id        | 640deede4a044dac877c5d8fca41deb5 |
| name      | user                             |
+-----------+----------------------------------+
[junoN1@node1 ~]$ openstack role add --project demo --user demo user
[junoN1@node1 ~]$

此处结果有些不一样,不知道是不是权限的问题;

[junoN1@node1 ~]$ openstack token issue
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field      | Value                                                                                                                                                                                   |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| expires    | 2019-01-23T07:05:31+0000                                                                                                                                                                |
| id         | gAAAAABcSAQrHZ5h-5wcTYTlv_XPWUGjixX9o2uOhnxYe5nZokmwO_n5Y5GeTK5b8YDO7rXKm0C9tbjweU7fII_4I6hJAUvwporqyEGlr6Za-P8lRDP5YjXVZyMeoGklW5vhp5jxSu4PEWhdr_P3GoxwIKOA4QdEhHXbawew3oM2vGESfyicZjg |
| project_id | 4bde9c33b2de4dbcab0b51b83e066ea8                                                                                                                                                        |
| user_id    | d5e9a83c7f28429f9111c382a4effd48                                                                                                                                                        |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
[junoN1@node1 ~]$ openstack project create --domain default --description "Service Project" service
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | Service Project                  |
| domain_id   | default                          |
| enabled     | True                             |
| id          | 6dfe7f2015504535900e64cc9ee698f8 |
| is_domain   | False                            |
| name        | service                          |
| parent_id   | default                          |
+-------------+----------------------------------+
[junoN1@node1 ~]$ openstack user create --domain default --password=glance glance
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | fcdbf2993ba4478290179f1b5acb23d0 |
| name                | glance                           |
| options             | {}                               |
| password_expires_at | None                             |
+---------------------+----------------------------------+
[junoN1@node1 ~]$ openstack role add --project service --user glance admin
[junoN1@node1 ~]$ openstack user create --domain default --password=nova nova
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 94163ecb32634df0a024fc195b4cf6d4 |
| name                | nova                             |
| options             | {}                               |
| password_expires_at | None                             |
+---------------------+----------------------------------+
[junoN1@node1 ~]$ openstack role add --project service --user nova admin
[junoN1@node1 ~]$ openstack user create --domain default --password=neutron
usage: openstack user create [-h] [-f {json,shell,table,value,yaml}]
                             [-c COLUMN] [--max-width <integer>] [--fit-width]
                             [--print-empty] [--noindent] [--prefix PREFIX]
                             [--domain <domain>] [--project <project>]
                             [--project-domain <project-domain>]
                             [--password <password>] [--password-prompt]
                             [--email <email-address>]
                             [--description <description>]
                             [--enable | --disable] [--or-show]
                             <name>
openstack user create: error: too few arguments
[junoN1@node1 ~]$ openstack user create --domain default --password=neutron neutron
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 00e71c562c2f4fbb8378c74d38bc2cbf |
| name                | neutron                          |
| options             | {}                               |
| password_expires_at | None                             |
+---------------------+----------------------------------+
[junoN1@node1 ~]$ openstack role add --project service --user neutron admin
[junoN1@node1 ~]$ openstack endpoint list
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                    |
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------+
| 28da9944def74c46bdae3f8bc1623ed7 | RegionOne | keystone     | identity     | True    | public    | http://node1:5000/v3/  |
| 3a5d4864cf504b839b5dd943e0b574e6 | RegionOne | keystone     | identity     | True    | admin     | http://node1:35357/v3/ |
| 512541ef88604e6eb985cc9bc7bd8bee | RegionOne | keystone     | identity     | True    | internal  | http://node1:5000/v3/  |
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------+

#################报错##################

(1)open /etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such f

(2)nohup sudo /usr/sbin/rabbitmq-server start &

ntp时间服务器配置

(1)NTP(Network TimeProtocol,网络时间协议)是用来使计算机时间同步的一种协议。它可以使计算机对其服务器或时钟源做同步化,它可以提供高精准度的时间校正(LAN上与标准间差小于1毫秒,WAN上几十毫秒),切可介由加密确认的方式来防止恶意的协议攻击。默认已经安装上了,如果没有的话:

yum -y install ntp

–配置文件:/etc/ntp.conf,端口为123

(2)搭建内网ntp服务器:

–修改配置文件:ntp.conf

restrict 127.0.0.1
restrict -6 ::1
restrict 10.101.1.0 mask 255.255.255.0  #允许10.101.1.0网段中的服务器访问本ntp服务器进行时间同步


# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap


# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 210.72.145.44
server 133.100.11.8
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
server 127.127.1.0                   #local clock 如果上面的服务器都无法同步时间,就和本地系统时间同步。127.127.1.0在这里是一个IP地址,不是网段。
fudge 127.127.1.0 stratum 10         #127.127.1.0 为第10层。ntp 和127.127.1.0同步完后,就变成了11层。  ntp是层次阶级的。同步上层服务器的stratum 大小不能超过或等于16。

###################问题解决##############

(1)客户端手动更新时间:常见报错https://www.jb51.net/article/108792.htm

[root@localhost ~]# ntpdate 10.101.1.225
16 Mar 10:42:05 ntpdate[27248]: no server suitable for synchronization found
[root@localhost ~]# ntpdate -d 10.101.1.225
16 Mar 10:50:22 ntpdate[27344]: ntpdate 4.2.6p5@1.2349-o Wed Apr 12 21:24:06 UTC 2017 (1)
Looking for host 10.101.1.225 and service ntp
host found : 10.101.1.225
transmit(10.101.1.225)
transmit(10.101.1.225)
transmit(10.101.1.225)
transmit(10.101.1.225)
transmit(10.101.1.225)
10.101.1.225: Server dropped: no data
server 10.101.1.225, port 123
stratum 0, precision 0, leap 00, trust 000
refid [10.101.1.225], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Mon, Jan  1 1900  8:05:43.000
originate timestamp: 00000000.00000000  Mon, Jan  1 1900  8:05:43.000
transmit timestamp:  e036e2f9.aa816538  Sat, Mar 16 2019 10:50:33.666
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000
16 Mar 10:50:35 ntpdate[27344]: no server suitable for synchronization found

–排查,使用Telnet时报错telnet: connect to address IP地址: No route to host,所以iptables -F清空所有规则;问题解决;

#####################参考#########

https://www.cnblogs.com/linypwb/p/5532535.html

死者的葬礼 ——T· S 艾略特

死者的葬礼

四月最残忍,从死了的

土地滋生丁香,混杂着

回忆和欲望,让春雨

挑动着呆钝的根。

冬天保我们温暖,把大地

埋在忘怀的雪里,使干了的

球茎得一点点生命。

夏天来得意外,随着一阵骤雨

到了斯坦伯吉西;我们躲在廊下,

等太阳出来,便到郝夫加登

去喝咖啡,又闲谈了一点钟。

我不是俄国人,原籍立陶宛,是纯德国种。

我们小时侯,在大公家做客,

那是我表兄,他带我出去滑雪撬,

我害怕死了。他说,玛丽,玛丽,

抓紧了呵。于是我们冲下去。

在山中,你会感到舒畅。

我大半夜看书,冬天去到南方。

 

这是什么根在抓着,是什么树杈

从这片乱石里长出来?人子呵,

你说不出,也猜不着,因为你只知道

一堆破碎的形象,受着太阳拍击,

而枯树没有阴凉,蟋蟀不使人轻松,

干石头发不出流水的声音。只有

一片阴影在这红色的岩石下,

(来吧,请走进这红岩石下的阴影)

我要指给你一件事,它不同于

你早晨的影子,跟在你后面走

也不象你黄昏的影子,起来迎你,

我要给你看恐惧在一把尘土里。

 

风儿吹得清爽,

吹向我的家乡,

我的爱尔兰孩子,

如今你在何方?

“一年前你初次给了我风信子,

他们都叫我风信子女郎。”

——可是当我们从风信子花园走回,天晚了,

你的两臂抱满,你的头发湿漉,

我说不出话来,眼睛看不见,我既不是

活的,也未曾死,我什么也不知道,

望着光亮的中心看时,是一片寂静

荒凉而空虚是那大海。

索索斯垂丝夫人,著名的相命家,

患了重感冒,但仍然是

欧洲公认的最有智慧的女人,

她有一副鬼精灵的纸牌。这里,她说,

你的牌,淹死的腓尼基水手,

(那些明珠曾经是他的眼睛。看!)

这是美女贝拉磨娜,岩石的女人,

有多种遭遇的女人。

这是有三根杖的人,这是轮盘,

这是独眼商人,还有这张牌

是空白的,他拿来背在背上,

不许我看见。我找不到。

那绞死的人。小心死在水里。

我看见成群的人,在一个圈里转。

谢谢你。如果你看见伊奎通太太,

就说我亲自把星象图带过去:

这年头人得万事小心呵。

 

并无实体的城,

在冬天早晨棕黄色的雾下,

一群人鱼贯地流过伦敦桥,人数是那么多,

我没有想到死亡毁坏了这许多人。

叹息,短促而稀少,吐了出来,

每个人的目光都盯着自己的脚。

流上山,流下威廉王大街,

直到圣玛丽乌尔诺教堂,在那里

大钟正沉沉敲着九点的最后一响。

那儿我遇到一个熟人,喊住他道:

“史太森!你记得我们在麦来船上!

去年你种在你的花园里的尸首,

它发芽了吗?今年会开花吗?

还是忽来严霜捣乱了它的花床?

哦,千万把狗撵开,那是人类之友,

不然他会用爪子又把它掘出来!

你呀,伪善的读者——我的同类,我的兄弟!”

北京北京

这是一篇之前的文章,可当作北京背包游的小攻略吧,除了阅兵部分,其余还是可以作为参考:

  • 出发前的小伴奏
    年轻人总是容易冲动,想不起是哪天了,一个想法突现,我与北京的第一次邂逅就这样开启了前奏,9月1号晚上,本以为到北京才能感受的阅兵的气氛,没想到在常州站就被质问了一遍,“包里有什么东西,香水,花露水,打火机,刀具······”幸好长着一张还算斯文的学生脸,警察叔叔只是细心的询问了一遍,我后面的那个哥们就没那么幸运喽,旅行包里面的东西全部翻出来,前后足有十分钟,(这不禁让我想起来了去年新疆乌鲁木齐的安检,我们前后被搜包搜了三次,前后一个半小时,一定是去年我基友太像不法分子喽,还是男大十八变,越变越帅咯)······
  • 北京初感之受保护的小鸟—咄咄逼人的北京
    硬座的一夜辗转反侧哒,迷迷糊糊不知道睡着了没有,不过在车上再一次感受到了阅兵的魅力,整个车厢至少一半的人是去看阅兵滴,在中国真是做什么事情都能赶上大潮啊,毕竟我国人多呐,感觉做什么事情都不会孤独咯,志同道合的人真是拥挤呀······
    到北京一出车站们,再一次被武警叫住喽,也是一问一答持续了好久(看来背个像炸药包一样的东西回头率果断高,而且吸引的都是帅气的武警和警察叔叔哒)。之前车水马龙的长安大街上空空荡荡,只有人行道上偶尔出现的稀稀疏疏的人,每个路灯底下架起了简易的安保棚,每个路口至少三名警察,武警随处可见,本来还想在长安大街的某个角落里建立起二人阅兵根据地呢,没想到两公里外就开始封路了,可想而知天安门周围两公里内都是全城戒严喽,一打听下午就要被全部赶出来了,心里顿时凉了一大半,幸好之前已经做好只能看见飞机的准备,用望远镜瞻仰一下战斗机飞速而过的最坏打算,原路返回,下一站天坛。
  • 凡事还需眼见为实咯,读完卷书,行万里路是必须的哇,尼玛回音壁
    草草结束午餐后,装逼二人组在天坛开启了自拍之旅,刚刚只知道是晴天,此时才发现天空万里无云,蓝的真假,看来中国政府果然名不虚传啊,阅兵蓝真棒!
    有一件事是必须要吐槽滴,小时候在物理书中,天坛的回音壁那是多么神奇呀,我和河马(东道主)还特意去试了一下,我在这头,他在那头,“河马~你个大傻逼,大傻逼。”兴冲冲跑到他面前,“河马,听到我讲什么了吗,刚刚一不小心夸了你哒!”“真假的,刚刚什么都没有听到也”,顿时泪奔,完全相信书里的内容就跟活在梦里一样啊,什么是真的,老毛说的好,没有调查就没有发言权······(本来想瞻仰一下老毛的,没想到点掐的不对呀,这几天阅兵不能把老毛放出来,这是后话)······来几张自拍照是必须的

此图像的alt属性为空;文件名为3.jpg

  • 圆明园我为啥来了
    圆明园,进去之前有个想法—作为具有历史警示作用的地方应该会是保留破坏之后的原状吧,到处是残垣绝壁,各种遗址······进去之后看到的是绿树成荫以及偶尔出现的院落,感觉就跟普通的公园差不多,走在大道上,“圆明园我为啥来了”一直在脑海中飘来飘去,在十二兽首介绍馆参观时,看到大部分的兽首都是爱国人士花费巨资买回来的,“把兽首拿回来是必须的,不过花巨资买回来,爱国之心没错,不过这种方法只会助长强盗的飞扬跋扈,况且每个都是花了上亿元买回,那都拿回来简直是奢望,这个社会就是这样,有的人将野蛮进行到底,不过人家腰板儿硬,不怕,公平总不会存在的,凡事都讲公平,那这个世界只会更乱,因为不管怎样,每个人心中公平的这杆秤都是不一样的,国家之间永远是弱肉强食,腰板儿粗壮说出来的话才有回声咯,对于个人来说,实力才是硬道理,凡事要争取,只有强大了别人才会鸟你,否则一切都是屁话哒。”既然来了,废墟还是要看的-西洋楼遗址,看着来来往往在废墟的残垣断壁下合影的人们,我的心中不禁闪过一个念头—来这里的人们也像欣赏其他风景一样,似乎这片废墟是能工巧匠的杰作,如欣赏断臂维纳斯的残缺美一样,走过,路过,BYEBYE……途中,每一个池塘都是荷叶密布,荷花若隐若现,岸上都是叫不出名字的花草,在北京,这样的天然氧吧还真不容易看见咯,这儿不失作为北京人茶余饭后散步的好去处(说的在偏激一点,那两个强盗要是没有那么一把火,这儿可能只有少数人能够进来观摩一下下,因了那把火,北京人又多了一个悠闲的娱乐场所,或许人类的内心总是这样矛盾的)。

此图像的alt属性为空;文件名为2-1024x522.jpg

  • 夜,鸟巢,奥运的故事只在过去
    世间永不停止的只有时间,驻足间,夜幕已经来到······
    奥运场馆总在奥运会期间辉煌一时,过后就是长久的沉寂,鸟巢也不例外,每当夜幕降临,鸟巢和水立方换上了华丽的荧光装,众多的摄影师不停的换着视角,只为拍下鸟巢华丽的姿态,作为比赛场馆的它走下神坛,化身背景,似乎也是一夜之间。不过,作为国家体育中心,环境还是非常适合锻炼的,早上锻炼,晚上散步,多爽。唯一感到惊讶的是在鸟巢下露营了一个晚上,居然没有遭到保安的骚扰。(不得不来段插曲,在地铁站刷着牙,用洗面奶,从清洁工阿姨和游客的眼神中我似乎看到了无底线的国度正在向我招手)

此图像的alt属性为空;文件名为4-1024x768.jpg

  • 本只为飞机而来,何憾之有咯
    早早告别鸟巢,卷铺盖走人喽,下一站,阅兵,走起。
    从地安门开始,有名的小吃一条街,打烊三天,吃货们只能望旗兴叹(每店闭门,只有国旗迎风飘扬),我们朝着预定的景山公园(老北京城最高的山丘,崇祯老爷爷就是在此依依不舍的再看一眼北京的夜景之后,去见祖宗十八代喽)进发,没想到北京继续他高高在上的姿态,只给我们这些个没有票的平民百姓施舍了闭门羹一顿咯。我们像斗鸡一样,怀着仅有的自尊,“一镜(望远镜)在手,阅兵我有”昂首绕过景山那冰冷的外墙,和数不清的来自五湖四海的兄弟姐妹门窝在故宫后院一条街上,静待飞机轰鸣。(没错,就是这么寒酸)

此图像的alt属性为空;文件名为5-572x1024.jpg

长城—我与保安躲猫猫
趁着阅兵这难得的好天气,长城,我来了。
早已做好跟长城共度良宵的准备,逗逼二人组在巨龙身上指点江山,各种自拍,寻找据点。终于,在唯一一座没有遮挡,没有摄像头,没有骚扰的敌楼上,我们打好地铺,掏出零食,欣赏着晚霞,静待最后一位游客的离开。在保安连绵不绝的呐喊声中,我们以为的最后一位游客(!!)依依

此图像的alt属性为空;文件名为6-1024x768.jpg

不舍的下山喽,我们怀着无比激动的心情,那种想欢呼又只能在心中呐喊的雀跃,正当我们觉得夜宿长城计划SO easy时,保安开始夜巡啦,看来以往这种想和长城亲密接触的人群不在少数呀,我们开始四处搜寻藏身之处,将装备藏于排水道中后,猴性大发,顺着长城边上一颗茂密的大树一跃而下,开始了长城脚下长达一个半小时的喂蚊子生涯,时而屹立时而蹲下,只为了跟蚊子来

此图像的alt属性为空;文件名为7-545x1024.jpg

架又不能打的无奈哒,此时恐怕只有多么痛的领悟能表达我的内心中波浪),夜安静的可以听到断断续续的脚步声,和第八楼方向的两个游客的交流,周围到处是虫鸣鸟叫的声响,以及头上被树叶遮挡的若隐若现的繁星(期间,一个大意的学生遗留下的一个包裹差点暴露了我们的行踪,手电筒就在我们半米开外一扫而过,为搭个帐篷也是拼了撒,搞得跟革命党人为躲避追捕,与敌人斗智斗勇般,差点就被抓去当标本啦,经此一战,河马说我为什么有种想跟你出来又不想跟你出来的感觉呢,尼玛,这算表白吗,一定是吓傻了吧,成为标本不还能上墙嘛,你说是不O(∩_∩)O)······保安的手电光终于随着我们渐趋规律的心跳消失了,我们的内心再起波澜,唰唰上树,翻越围墙,(古代城墙几米开外必定没有树,我们这种身手的人都可以轻松上树,更何况战士了,不过上树这两个字总让我想起某种动物,也是醉了)掏出零食,大快朵颐。期间几次不情愿的停下双嘴,学起古代战士将耳朵贴在长城地砖上,以确定今夜长城属于我俩,雄踞于关外关内之间,这叫二夫当关哒(请容许我装会逼,O(∩_∩)O,只是太天真)。长城距离北京八十公里左右,群山环绕,绿树成荫,是北京观赏夜景最佳地带,我们并排而卧,享受这独一无二的夜晚。出来旅游总是睡觉最有规律的时刻,不到十点就进入了梦乡,静待明早的日出,晚安,长城。

  • 嗨翻天的老外~~保安巡逻队····

闹钟在凌晨四点喊醒了睡梦中的两头猪,拉开帐篷,竟然感到丝丝凉意,我们裹着睡袋,带着惺忪的双眼,环顾长城左右,欣赏长城略带朦胧的黑壮的倩影,八楼的手电在夜空摇曳,居然还有其他“守卫者”,我用手电对他

们做出了回应,使用着我也不懂的光的语言。收拾完毕,正准备前往十二楼时不远处传来了哔哩啪啦的脚步声,一队人马骤然出场,首先出场的是保安代表队,保安迈步有点狂,左擎光,右牵棍,警帽棉裘,六骥卷平岗,为赶彻夜不安民,张口喝,你们叼:接下来出场的是欧洲代表队,彻夜狂欢意正浓,眼惺忪,又何妨!瑟瑟风中,只为等日出,他日定当再会首,夜长城,我还来。 看到我们的帐篷,保安让我们赶紧收了,而老外是满口的“good!””great,bravo!”天蒙蒙亮,才发现长城上空裹着一层薄薄的雾纱,保安说今天看不到日出啦,我们极不情愿的将帐篷收了,特意和老外来了张合照,为我们的统一战线喝彩。欧洲代表队简直颜值爆表哒,美女和另外两个较成熟的哥们来自俄罗斯,是北大的

留学生,那一口流利的汉语让我肃然起敬,她充当五人的翻译;颜值担当的大帅哥来自法国,年龄十七,那undercut发型外加无可挑剔的侧脸,简直帅翻了(完了,这不会就是一见钟情吧),是五人组的摄像师,看他在保安室前面采访队员的感受,太有型了。另一张略显稚气的脸庞来自德国,十八岁,刚刚高中毕业,到中国后遇到另外几个人就一起了,下一站去日本,然后澳大利亚,他出来看一看世界,我问他什么时候回去上学,“You know ,I am so yuang”一句话就看出了他们与众不同的生活态度,他说他玩的差不多了才会回去继续读书,现在不急,他想要更多的了解这个世界,他正在好好的享受青春岁月。这个哥们及其随意,带着他的铺盖,几乎是走到哪睡到哪,就是这么任性。他让我不禁想到了当下的中国,感觉我们年少的时候总想着快点长大,然后就开始了长达十几年的校园生活,然后就感叹时间过得好快,好想回到小时候,或者想着快点出去工作,可想想我们以后至少三十年要工作呢,急什么呢?这就是浮躁,青春期我们的想法总是不着边际,这时候是培养创新能力最好的时期,填鸭式的教育只会让我们的想法趋于单一,然后大家就几乎是一个模子造出来的一样。和他们依依不舍的告别后,我们到长城的星级旅游厕所无底线的用洗手液洗着头发,感受着北京的刺骨的冰水。

  • 阅兵结束了,晴天也结束了
    这再一次体现了人是可以改造自然的,中国政府可以对雨天说NO。北京只要一下雨,不管是什么季节总是让人感到丝丝凉意,不过对于游览十三陵是需要这样的天气的, 对于历史经典,有导游蹭那是一件全身轻松的事情,毕竟历史韵味太浓,走马观花就真的只能看看喽(为防止类似我这种不要脸的游客,现在的导游大都采取无线蓝牙耳机讲解都方式,这不是要赶尽杀绝嘛,不过技术的进步总是为懒人服务的,经典大都覆盖无线网络外加扫码语音解说,算是一个福音)。走进定陵的地下宫殿,第一次感受皇帝陵墓的构造之巧夺天工以及防盗技术的精湛,在长陵感受了下朱棣的个人魅力以及全球最大的金丝楠木宫殿,茂陵体验了下皇帝祭祀的繁杂及规格之高。十三陵年代较近,且清朝为巩固民族关系派重兵看守和维护,是
    至今保存最完好及最大的墓葬群,且没有盗墓现象,堪称奇迹。雨天改变了原有的在天安门露宿一晚的计划,也没有时间去看升旗仪式,回基友宿舍修整了一夜,第二天又是在雨中游览故宫,继续蹭导游,了解了下真实的宫廷生活:官员上朝及打卡,皇帝要在太阳光照到中国最东边的土地上的时候屁股必须落在龙椅之上,在太阳光照到太和殿屋顶时结束,前后不过20多分钟,每个官员站在太和殿前的场地上,一人一块砖,一年只能三天不打卡,其他时间没有理由,没有借口,到太和殿看三样东西,门前的狮子,龙椅,地砖。那两头狮子是全国规格最高的狮子,辨识标志是看他帅不帅(头上梳了多少簇头髻便知),龙椅第一眼以为是金子做的,实际上是木头(五行中认为木代表生命,活人用木质的东西),太和殿中的地砖比同等黄金还贵重,还有就是故宫中除了御花园,其他地方没有树,太多东西只能到此一游才可体会哒。
  • 欧说:对于学生党而言,到北京玩最大的感受就是学生证太好用,基本上景点都是20元左右;其次是到历史韵味较重的地方一定要学会蹭导游或者收听语音解说,再者,如果有来自五湖四海的同学,那么就厚脸皮的去蹭蹭蹭喽(嘘!)。不过感觉坑了人家太多,带他第一次露宿,鸟巢和长城上我睡得爽翻天,他基本上都是到十二点才睡哒,同时,我总是突发奇想就去做某些事情,他陪着我走了不少冤枉路,哈哈,有一个愿意陪着一起走冤枉路的朋友真好。(别想歪哒,他叫我老大,此次纯粹是去坑小弟的)。我觉得旅行最好是带着装备的,这样能深入的感受当地风情,对于充电,吃饭和休整的时候把移动电源等充满;洗澡可找钟点房和澡堂,不是问题;喜欢骑行或徒步从一个景点到另一个景点,驱车直达总觉得少了点什么,所以走弯路对于行者而言是必须的,因为旅行就是身体跟着灵魂在路上游荡。