Lvs+keepalived集群架构服务应用

    0.lvs负载均衡集群介绍

负载均衡(Load Balance)集群提供了一种廉价、有效、透明的方法,来扩展网络设备和服务器的负载、带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

搭建负载均衡服务的需求

  • 把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间,提升用户体验;
  • 单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后将结果汇总,返回给用户,系统处理能力得到大幅度提高。
  • 7×24的服务保证,任意一个或多个有限后面节点设备宕机,要求不能影响业务。

在负载均衡集群中,所有计算机节点都应该提供相同的服务。集群负载均衡器截获所有对该服务的入站请求。然后将这些请求尽可能地平均地分配在所有集群节点上。

  • LVS(Linux Virtual Server)介绍

lvs项目介绍http://www.linuxvirtualserver.org/zh/lvs1.html

LVS负载均衡调度技术是在Linux内核中实现的,因此,被称之为Linux虚拟服务器(LlnuxVinualServer)。我们使用该软件配置LVS时候,不能直接配置内核中的ipvs,而需要使用iPvs的管理工具ipvsadm进行管理,当然,后文我们会讲通过keepalived软件直接管理ipvs,并不是通过ipvsadm来管理ipvs。

LVS技术点小结:

1、真正实现调度的工具是IPVS,工作在linux内核层面。

2、LVS自带的IPVS管理工具是1pvsadm。

3、keepalived实现管理IPVS及负载均衡器的高可用。

4、Redhat工具Piranha WEB管理实现调度的工具IPVS

  • LVS体系结构与工作原理简单描述

LVS集群负载均衡器接受服务的所有入站客户端计算机请求,并根据调度算法决定哪个集群节点应该处理回复请求。负载均衡器(简称LB)有时也被称为Lvs Director(简称Director)。

LVS虚拟服务器的体系结构如下图所示,一组服务器通过高速的局域网或者地理分布的广域网相互连接,在它们的前端有一个负载调度器(Load Balancer)。负载调度器能无缝地将网络请求调度到真实服务器上,从而使得服务器集群的结构对客户是透明的,客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务集群中透明地加入和删除一个节点来达到,通过检测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的,我们称之为Linux虚拟服务器(LinuxVirtualServer)。

  • LVS相关术语命名约定

虚拟IP地址件(virtual IP Address):缩写VIP,VIP为Director用于向客户端计算机提供服务的IP地址。比如:www.etiantian.org域名就要解析到VIP上提供服务。

真实IP地址很(Real serverIP Address):缩写RIP,在集群下面节点上使用的IP地址,物理IP地址。

Director的IP地址(Director IP address):缩写DIP,Director用于连接内外网络的IP地址,物理网卡上的IP地址。是负载均衡器上的IP

客户端主机IP地址(client IP Address):缩写CIP,客户端用户计算机请求集群服务器的IP地址,该地址用作发送给集群的请求的源IP地址。

  1. ARP协议介绍

ARP协议,全称“Address Resolution Profocol”,中文名是地址解析协议,使用ARP协议可实现通过IP地址获得对应主机的物理地址(MAC地址)。

在TCP/IP的网络环境下,每个联网的主机都会被分配一个32位的IP地址,这种互联网地址是在网际范围标识主机的一种逻辑地址。为了让报文在物理网路上传输,还必须要知道对方目的主机的物理地址(MAC)才行。这样就存在把IP地址变换成物理地址的地址转换的问题。

在以太网环境,为了正确地向目的主机传送报文,必须把目的主机的32位IP地址转换成为目的主机48位以太网的地址(NIAC地址)。这就需要在互连层有一个服务或功能将IP地址转换为相应的物理地址(MAC地址),这个服务或者功能就是ARP协议。所谓的“地址解析”,就是主机在发送帧之前将目标IP地址转换成目标MAC地址的过程。ARP协议的基本功能就是通过目标设备的IP地址,查询目标设备的MAC地址,以保证主机间互相通信的顺利进行。

arp协议是三层协议,工作于二层

ARP协议和DNS有点相像之处。不同点是:DNS是在域名和1P之间的解析,另外,ARP协议不需要配置服务,而DNS要配置服务才行。

ARP协议要求通信的主机双方必须在同一个物理网段(即局域网环境)

  • ARP缓存表是把双刃剑

(1)主机有了arp缓存表,可以加快ARP的解析速度,减少局域网内广播风暴。

(2)正是有了arp缓存表,给恶意黑客带来了攻击服务器主机的风险,这个就是arp欺骗

(3)切换路由器,负载均衡器等设备时,可会导致短时网络中断。

  • ARP在生产环境产生的问题及解决办法
  • ARP病毒,ARP欺骗。
  • 高可用服务器对之间切换时要考虑ARP缓存的问题。
  • 路由器等设备无缝迁移时要考虑ARP缓存的问题,例如:更换办公室的路由器。
  • ARP欺骗原理

ARP攻击就是通过伪造IP地址和MAC地址对实现ARP欺骗的,如果一台主机中了ARP病毒,那么它就能够在网络中产生大量的ARP通信量(它会以很快的频率进行广播),以至于使网络阻塞,攻击者只要持续不断的发出伪造的ARP响应包就更改局域网中目标主机ARP缓存中的IP-MAC条目,造成网络中断或中间人攻击。

ARP攻击主要是存在于局域网网络中,局域网中若有一个人感染ARP木马,则感染该ARP木马的系统将会试图通过“ARP欺骗”手段截获所在网络内其它计算机的通信信息,并因此造成网内其它计算机的通信故障。

  • 服务器切换ARP问题

当网络中一台提供服务的机器宕机后,当在其他运行正常的机器添加宕机的机器的IP时,会因为客户端的ARP table cache的地址解析还是宕机的机器的MAC地址。从而导致即使在其他运行正常的机器添加宕机的机器的IP,也会发生客户依然无法访问的情况。

解决办法是:当机器宕机,IP地址迁移到其他机器上时,需要通过。arping命令来通知所有网络内机器清除其本地的ARP table cache,从而使得客户机访问时重新广播获取MAC地址。这个在自己开发脚本实现服务器的高可用时是要必须考虑的问题之一,几乎所有的高可用软件都会考虑这个问题。ARP广播而进行新的地址解析。

arping  [  -AbDfhqUV]   [ -c  count]  [ -w deadline]  [ -s source]  -I interface destination

例如:/sbin/arping -I eth0 -c 3 -s 192.168.80.102 192.168.80.2

  1. LVS集群的3种工作模式介绍

IP虚拟服务器软件IPVS

在调度器的实现技术中,IP负载均衡技术是效率最高的。在己有的IP负载均衡技术中有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器,我们称之为VS/NAT技术(virtual Server via Network Address Translation),大多数商业化的IP负载均衡调度器产品都是使用NAT的方法,如Cisco的LocalDirector、F5、Netscaler的Big/IP和Alteon的ACEDirector。

在分析VS/NAT的缺点和网络服务的非对称性的基础上,我们提出通过IP隧道实现虚拟服务器的方法VS/TUN(Virtual server via IP Tunneling)和通过直接路由实现虚拟服务器的方法VS/DR(Virtual Server via Direct Routing),它们可以极大地提高系统的伸缩性。所以,IPVS软件实现了这三种IP负载均衡技术,它们的大致原理如下(我们将在其他章节对其工作原理进行详细描述)。淘宝开源的模式FULLNAT。FULLNAT(Virtual Server via FULL Network AddressTranslation).

  • DR模式特点

1、通过在调度器LB上修改数据包的目的MAC地址实现转发,注意,源正地址仍然是CIP,目的IP地址仍然是VIP。

2、请求的报文经过调度器,而RS响应处理后的报文无需经过调度器LB,因此,并发访问量大时使用效率很高(和NAT模式比)。

3、因DR模式是通过MAC地址的改写机制实现的转发,因此,所有RS节点和调度器LB只能在一个局域网LAN中(小缺点)。

4、需要注意RS节点的VIP的绑定(lo:vip/32,101,vip/32)和ARP抑制问题。,

5、强调下:RS节点的默认网关不需要是调度器LB的DIP,而直接是IDC机房分配的上级路由器的IP(这是RS带有外网正地址的情况),理论讲:只要RS可以出网即可,不是必须要配置外网IP。

6、由于DR模式的调度器仅进行了目的MAC地址的改写,因此,调度器LB无法改变请求的报文的目的端口(和NAT要区别)。

7、当前,调度器LB支持几乎所有的UNIX,LINUX系统,但目前不支持WINDOWS系统。真实服务器RS节点可以是WINDOWS系统。

8、总的来说DR模式效率很高,但是配置也较麻烦,因此,访问量不是特别大的公司可以用hoproxy/nginx取代之。这符合运维的原则:简单、易用、高效。日1000-2000w PV或并发请求1w以下都可以考虑用hoproxy/nginx

9、直接对外的访问业务,例如:web服务做RS节点,RS最好用公网护地址。如果不直接对外的业务,例如:MySQL,存储系统RS节点,最好只用内部IP地址。

  • NAT模式特点

1、NAT技术将请求的报文(通过DNAT方式改写)和响应的报文(通过SNAT方式改写),通过调度器地址重写然后在转发给内部的服务器,报文返回时在改写成原来的用户请求的地址。

2、只需要在调度器LB上配置WAN公网IP即可,调度器也要有私有LAN IP和内部RS节点通信。

3、每台内部RS节点的网关地址,必须要配成调度器LB的私有LAN内物理网卡地址(LDIP),这样才能确保数据报文返回时仍然经过调度器LB。

4、由于请求与响应的数据报文都经过调度器LB,因此,网站访问量大时调度器LB有较大瓶颈,一般要求最多10-20台节点。

5、NAT模式支持对IP及端口的转换,即用户请求10.0.0.1:80,可以通过调度器转换到RS节点的10.0.0.2:8080(DR和TUN模式不具备的)。

6、所有NAT内部RS节点只需配置私有LANIP即可。

7、由于数据包来回都需要经过调度器,因此,要开启内核转发net.ipv4.ip_forward=1,当然也包括iptables防火墙的forward功能(DR和TUN模式不需要)。

  • TUN模式

1、负载均衡器通过把请求的报文通过IP隧道(ipip隧道,高级班讲这个)的方式(请求的报文不经过原目的地址的改写(包括MAC),而是直接封装成另外的IP报文)转发至真实服务器,而真实服务器将响应处理后直接返回给客户端用户。

2、由于真实服务器将响应处理后的报文直接返回给客户端用户,因此,最好RS有一个外网IP地址,这样效率才会更高。理论上:只要能出网即可,无需外网IP地址。

3、由于调度器LB只处理入站请求的报文。因此,此集群系统的吞吐量可以提高10倍以上,但隧道模式也会带来一定的系统开销。TUN模式适合LAN/WAN。

4、TUN模式的LAN环境转发不如DR模式效率高,而且还要考虑系统对IP隧道的支持问题。

5、所有的RS服务器都要绑定VIP,抑制ARP,配置复杂。

6、LAN环境一般多采用DR模式,WAN环境可以用TUN模式,但是当前在WAN环境下,请求转发更多的被haproxy/nginx/DNS调度等代理取代。因此,TUN模式在国内公司实际应用的已经很少。跨机房应用要么拉光纤成局域网,要么DNS调度,底层数据还得同步。

7、直接对外的访问业务,例如:web服务做RS节点,最好用公网IP地址。不直接对外的业务,例如:MySQL,存储系统RS节点,最好用内部IP地址。

  • LVS的三种模式优缺点比较

 

  1. LVS的调度算法

固定调度算法:rr,wrr,dh,sh

动态调度算法:wlc,lc,lb1c,lblcr,SED,NQ(后两种官方站点没提到,编译LVS,make过程可以看到)

rr:轮循调度(Round一Robin),它将请求依次分配不同的RS节点,也就是在RS节中均摊请求。这种算法简单,但是只适合于RS节点处理性能相差不大的情况。

wrr:加权轮循调度(Weighted Round-Robin),它将依据不同RS节点的权值分配任务,权值较高的RS将优先获得任务,并且分配到的连接数将比权值较低的RS节点更多,相同权值的RS得到相同数目的连接数。

dh:目的地址哈希调度(Destination Hashing)以目的地址为关键字查找一个静态hash表来获得需要的RS。

sh:源地址哈希调度(Source Hashing) 以源地址为关键字查找一个静态hash表来获得需要的RS。

wlc加权最小连接数调度(Weighted Least-Comnection) (WLC) 具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。假设各台RS的权值一次为Wi(l = 1..n),当前的TCP连接数依次为Ti(l=1..n)一次选取Ti/Wi为最小的RS作为下一个分配的RS

lc最小连接数调度(Least-Connection),IPVS表存储了所有的活动的连接。把新的链接请求发送到当前连接数最小的RS。

LBLC 基于局部性的最少链接(Locality-Based Least Connections)针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用“最少链接” 的原则选出一个可用的服务器,将请求发送到该服务器。

LBLCR 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按“最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按“最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度

SED 最短的期望的延迟(Shortest Expected Delay Scheduling SED)

NQ 最少队列调度(Never Queue Scheduling NQ)

  • LVS的调度算法的生产环境选型
  • 一般的网络服务,如Mail、MySQL等,常用的LVS调度算法为:

a.基本轮询调度rr

b.加权最小连接调度wrr

c.加权轮询调度w1c

  • 基于局部性的最少链接LBLC和带复制的基于局部性最少链接LBLCR主要应用于webCache和DbCache集群,但是我们很少这样用。一致性哈希。
  • 源地址散列调度SH和目标地址散列调度DH可以结合使用在防火墙集群中,它可以保证整个系统的唯一出入口。
  • 最短预期延时调度SED和不排队调度NQ主要是对处理时间相对比较长的网络服务

实际使用中,这些算法的适用范围不限于这些。我们最好参考内核中的连接调度算法的实现原理,根据具体的业务需求合理的选型。

  1. lvs的安装部署

在安装好keepalived的机器上部署lvs

lsmod|grep ip_vs     #查看ip_vs模块,安装keepalived后默认会加载ip_vs模块,也可以安装lvs

ip_vs                 125694  0                                    #后执行ipvsadm命令加载

libcrc32c               1246  1 ip_vs

ipv6                  334932  137 ip_vs

这里选择yum安装lvs

yum install ipvsadm -y           #yum安装lvs

sed -i ‘s#net.ipv4.ip_forward = 0#net.ipv4.ip_forward = 1#g’ /etc/sysctl.conf  #修改内核转发

sysctl -p

编译安装LVS方式如下

yum install libnl* popt* -y

wget http://linuxvirtualserver.org/software/kernel-2.6/ipvsadm-1.26.tar.gz

tar xvf ipvsadm-1.26.tar.gz

cd ipvsadm-1.26

make

make install

ipvsadm     #加载ip_vs模块或(modprobe ip_vs)

lsmod |grep ip_vs #查看

注意:Centos5.X安装lvs, 使用1.24版本。不要用1.26。

  • ipvsadm命令相关参数

-A, –add-service              Add a virtual service

-C, –clear              Clear the virtual server table.

-D, –delete-service             Delete a virtual service,

-d, –delete-server              Remove a real server from a virtual  service.

-g,  –gatewaying  Use gatewaying (direct routing)    #DR模式

-i, –ipip  Use ipip encapsulation (tunneling)        #TUN模式

-m,  –masquerading   Use masquerading (network access translation, or NAT). #NAT模式

-p, –persistent [timeout]  Specify  that  a  virtual service is persistent #会话保持

-w, –weight weight    #权重

-L, -l, –list        List the virtual server table if no argument is specified

-s, –scheduler scheduling-method     #调度算法

–set tcp tcpfin udp         Change the timeout values used for IPVS connections.

-t, –tcp-service service-address      Use TCP service. The  service-address  is  of the form host[:port].

  • 配置lvs服务并添加RS

ip addr add 192.168.80.11/24 dev eth0 label eth0:1

ipvsadm -C

ipvsadm –set 30 5 60

ipvsadm -A -t 192.168.80.11:80 -s rr

ipvsadm -a -t 192.168.80.11:80 -r 192.168.80.103:80 -g

ipvsadm -a -t 192.168.80.11:80 -r 192.168.80.104:80 -g

  • 配置所有RS绑定VIP并抑制arp

配置别名ifconfig eth0:0 10.0.0.10/24 up(Centos7已经淘汰)

辅助IP:ip addr add 192.168.80.99/24 dev eth0

ip addr add 192.168.80.11/32 dev lo label lo:1

route add -host 192.168.80.11 dev lo

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

  • 有关arp_ignore的相关介绍:

0 – (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求

1 – 只回答目标IP地址是来访网络接口本地地址的ARP查询请求

2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内

3 – 不回应该网络界面的arp请求,而只对设置的唯一和连接地址做出回应

4-7 – 保留未使用

8 -不回应所有(本地地址)的arp查询

  • 有关arp_announce的相关介绍

arp_announce:对网络接口上,本地IP地址的发出的,ARP回应,作出相应级别的限制: 确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口

0 – (默认) 在任意网络接口(eth0,eth1,lo)上的任何本地地址

1 -尽量避免不在该网络接口子网段的本地地址做出arp回应. 当发起ARP请求的源IP地址是被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口上的子网段内ip之一.如果改来访IP不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理.

2 – 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送

  1. lvs相关企业案例
  • 常见的LVS负载均衡高可用解决方案

(1)通过开发上面的脚本来解决,如果负载均衡器硬件坏了。几分钟或几秒从其他备机上完成新的部署,如果做的细的,还可以写脚本来做调度器之间的切换,早期的办法,还是比较笨重的,目前己不再推荐使用。

(2)keepalived+LVS方案,这是老男孩极力推荐的当前最优方案,因为这个方案符合简单、易用、高效的运维原则,也是接下来重点讲解的负载均衡及高可用解决方案。

  • LVS集群分发请求RS不均衡生产环境实战解决

生成环境中ipvsadm -Ln发现两台RS的负载不均衡,一台有很多请求,一台没有。并且没有请求的那台RS经测试服务正常,lo:VIP也有。但是就是没有请求。

TCP  192.168.80.11:80 rr  wrr persistent 10

-> 192.168.80.103:80            Route   1      0          1

-> 192.168.80.104:80            Route   1      8          12758

问题原因:

persistent10的原因,persistent会话保持,当clientA访问网站的时候,LVS把请求分发给了104,那么以后clientA再点击的其他燥作其他请求,也会发送给104这台机器。

到keepalived中注释掉persistent10然后/etc/init.d/keepalived reload,然后可以看到以后负载均衡两边都请求都均衡了。

其他导致负载不均衡的原因可能有:

1、LVS自身的会话保持参数设置(-p300,persistent 300)。优化:大公司尽量用cookies替代session

2、LVS调度算法设置,例如:rr,wrr,wlc,lc算法。

3、后端RS节点的会话保持参数,例如:apache的keealive参数。.

4、访问量较少的情况,不均衡的现象更加明显

5、用户发送的请求时间长短,和请求资源多少大小。

  • 大规模网站sesson会话保持思路及实践配置

http://oldboy.blog.51cto.com/2561410/1331316

http://oldboy.blog.51cto.com/2561410/1323468

  • LVS故障排错理论及实战讲解

排查的大的思路就是,要熟悉LVS的工作原理过程,然后根据原理过程来排查。例如:

1、调度器上LVS调度规则及IP的正确性。

2、RS节点上VIP绑定和arp抑制的检查。

  生产处理思路:

  • 对RS绑定的vip做实时监控,出问题报警或者自动处理后报警。
  • 把RS绑定的vip做成配置文件,例如:vi/etc/sysconfig/network-scripts/lo:0。

  ARP抑制的配置思路

  • 如果是单个VIP,那么可以用stop传参设置O。
  • 如果RS端有多个VIP绑定,此时,即使是停止VIP绑定也一定不要置O。

if [ ${#VIP[@]} -le 1 ];then

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

fi

3、RS节点上自身提供服务的检查(DR不能端口转换)

4、辅助排除工具有tcpdump,ping等。

  • 多台RS代码上线方案思路

(lvs,nglnx,haproxy,f5等下的集群节点php,java程序如何上下线)

集群节点多,上线时希望最大限度的不影响用户体验。

1)通过ipvsadm命令下线机器。

ipvsadm -d -t 192.168.1.181:80 -r 192.168.1.179:80

2)通过url做健康检查,然后,移走健康检查文件:这样director会把此RS从转发池中移除。

  • LVS性能调优

1、关闭iptables,换硬件防火墙。大流量时,iPtables是一个性能瓶颈,关闭或换换硬件防火墙。

2、ipvsadm –set tcp tcpfin udp

3、内核优化

  1. 配置keepalived+lvs

ipvsadm -C           #清空虚拟服务表

ip addr del 192.168.80.11/24 dev eth0  #删除虚拟IP

vi /etc/keepalived/keepalived.conf

! Configuration File for keepalived

 

global_defs {

notification_email {

acassen@firewall.loc

failover@firewall.loc

sysadmin@firewall.loc

}

notification_email_from Alexandre.Cassen@firewall.loc

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id LVS_1

}

 

vrrp_instance VI_1 {

 state MASTER

interface eth0

virtual_router_id 50

 priority 150

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

192.168.80.11/24

}

}

 

virtual_server 192.168.80.11 80 {

delay_loop 6

lb_algo wrr

lb_kind DR

persistence_timeout 50

protocol TCP

 

real_server 192.168.80.103 80 {

weight 1

TCP_CHECK {

connect_timeout 5

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

}

real_server 192.168.80.104 80 {

weight 1

TCP_CHECK {

connect_timeout 5

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

}

}

在backup lvs上只需修改黑体部分即可

测试:

在物理机的hosts文件修改主机记录,

192.168.80.11 www.etiantian.org bbs.etiantian.org blog.etiantian.org

访问www.etiantian.org测试

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇