国产成人一区三区,捆绑调教一区二区三区,全国精品久久少妇

Deploying Highly Available Virtual Interfaces With Keepalived

abin — Sun, 01 Nov 2015 13:06:00 GMT

Linux is a powerhouse when it comes to networking, and provides a full featured and high performance network stack. When combined with web front-ends such asHAProxy, lighttpd, Nginx, Apache or your favorite application server, Linux is a killer platform for hosting web applications. Keeping these applications up and operational can sometimes be a challenge, especially in this age of horizontally scaled infrastructure and commodity hardware. But don't fret, since there are a number of technologies that can assist with making your applications and network infrastructure fault tolerant.

One of these technologies, keepalived, provides interface failover and the ability to perform application-layer health checks. When these capabilities are combined with the Linux Virtual Server (LVS) project, a fault in an application will be detected by keepalived, and the virtual interfaces that are accessed by clients can be migrated to another available node. This article will provide an introduction to keepalived, and will show how to configure interface failover between two or more nodes. Additionally, the article will show how to debug problems with keepalived and VRRP.

What Is Keepalived?

The keepalived project provides a keepalive facility for Linux servers. This keepalive facility consists of a VRRP implementation to manage virtual routers (aka virtual interfaces), and a health check facility to determine if a service (web server, samba server, etc.) is up and operational. If a service fails a configurable number of health checks, keepalived will fail a virtual router over to a secondary node. While useful in its own right, keepalived really shines when combined with the Linux Virtual Server project. This article will focus on keepalived, and a future article will show how to integrate the two to create a fault tolerant load-balancer.

Installing KeepAlived From Source Code

Before we dive into configuring keepalived, we need to install it. Keepalived is distributed as source code, and is available in several package repositories. To install from source code, you can execute wget or curl to retrieve the source, and then run "configure", "make" and "make install" compile and install the software:

$ wget http://www.keepalived.org/software/keepalived-1.1.17.tar.gz  $ tar xfvz keepalived-1.1.17.tar.gz   $ cd keepalived-1.1.17  $ ./configure --prefix=/usr/local  $ make && make install

In the example above, the keepalived daemon will be compiled and installed as /usr/local/sbin/keepalived.

Configuring KeepAlived

The keepalived daemon is configured through a text configuration file, typically named keepalived.conf. This file contains one or more configuration stanzas, which control notification settings, the virtual interfaces to manage, and the health checks to use to test the services that rely on the virtual interfaces. Here is a sample annotated configuration that defines two virtual IP addresses to manage, and the individuals to contact when a state transition or fault occurs:

# Define global configuration directives global_defs {     # Send an e-mail to each of the following     # addresses when a failure occurs    notification_email {        matty@prefetch.net        operations@prefetch.net    }    # The address to use in the From: header    notification_email_from root@VRRP-director1.prefetch.net     # The SMTP server to route mail through    smtp_server mail.prefetch.net     # How long to wait for the mail server to respond    smtp_connect_timeout 30     # A descriptive name describing the router    router_id VRRP-director1 }  # Create a VRRP instance  VRRP_instance VRRP_ROUTER1 {      # The initial state to transition to. This option isn't     # really all that valuable, since an election will occur     # and the host with the highest priority will become     # the master. The priority is controlled with the priority     # configuration directive.     state MASTER      # The interface keepalived will manage     interface br0      # The virtual router id number to assign the routers to     virtual_router_id 100      # The priority to assign to this device. This controls     # who will become the MASTER and BACKUP for a given     # VRRP instance.     priority 100      # How many seconds to wait until a gratuitous arp is sent     garp_master_delay 2      # How often to send out VRRP advertisements     advert_int 1      # Execute a notification script when a host transitions to     # MASTER or BACKUP, or when a fault occurs. The arguments     # passed to the script are:     #  $1 - "GROUP"|"INSTANCE"     #  $2 = name of group or instance     #  $3 = target state of transition     # Sample: VRRP-notification.sh VRRP_ROUTER1 BACKUP 100     notify "/usr/local/bin/VRRP-notification.sh"      # Send an SMTP alert during a state transition     smtp_alert      # Authenticate the remote endpoints via a simple      # username/password combination     authentication {         auth_type PASS         auth_pass 192837465     }     # The virtual IP addresses to float between nodes. The     # label statement can be used to bring an interface      # online to represent the virtual IP.     virtual_ipaddress {         192.168.1.100 label br0:100         192.168.1.101 label br0:101     } }

The configuration file listed above is self explanatory, so I won't go over each directive in detail. I will point out a couple of items:

Each host is referred to as a director in the documentation, and each director can be responsible for one or more VRRP instances
Each director will need its own copy of the configuration file, and the router_id, priority, etc. should be adjusted to reflect the nodes name and priority relative to other nodes
To force a specific node to master a virtual address, make sure the director's priority is higher than the other virtual routers
If you have multiple VRRP instances that need to failover together, you will need to add each instance to a VRRP_sync_group
The notification script can be used to generate custom syslog messages, or to invoke some custom logic (e.g., restart an app) when a state transition or fault occurs
The keepalived package comes with numerous configuration examples, which show how to configure numerous aspects of the server

Starting Keepalived

Keepalived can be executed from an RC script, or started from the command line. The following example will start keepalived using the configuration file /usr/local/etc/keepalived.conf:

$ keepalived -f /usr/local/etc/keepalived.conf

If you need to debug keepalived issues, you can run the daemon with the "--dont-fork", "--log-console" and "--log-detail" options:

$ keepalived -f /usr/local/etc/keepalived.conf --dont-fork --log-console --log-detail

These options will stop keepalived from fork'ing, and will provide additional logging data. Using these options is especially useful when you are testing out new configuration directives, or debugging an issue with an existing configuration file.

Locating The Router That is Managing A Virtual IP

To see which director is currently the master for a given virtual interface, you can check the output from the ip utility:

VRRP-director1$ ip addr list br0 5: br0:  mtu 1500 qdisc noqueue state UNKNOWN      link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff     inet 192.168.1.6/24 brd 192.168.1.255 scope global br0     inet 192.168.1.100/32 scope global br0:100     inet 192.168.1.101/32 scope global br0:101     inet6 fe80::224:8cff:fe4e:7f6/64 scope link         valid_lft forever preferred_lft forever  VRRP-director2$ ip addr list br0 5: br0:  mtu 1500 qdisc noqueue state UNKNOWN      link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff     inet 192.168.1.7/24 brd 192.168.1.255 scope global br0     inet6 fe80::224:8cff:fe4e:7f6/64 scope link         valid_lft forever preferred_lft forever

In the output above, we can see that the virtual interfaces 192.168.1.100 and 192.168.1.101 are currently active on VRRP-director1.

Troubleshooting Keepalived And VRRP

The keepalived daemon will log to syslog by default. Log entries will range from entries that show when the keepalive daemon started, to entries that show state transitions. Here are a few sample entries that show keepalived starting up, and the node transitioning a VRRP instance to the MASTER state:

Jul  3 16:29:56 disarm Keepalived: Starting Keepalived v1.1.17 (07/03,2009) Jul  3 16:29:56 disarm Keepalived: Starting VRRP child process, pid=1889 Jul  3 16:29:56 disarm Keepalived_VRRP: Using MII-BMSR NIC polling thread... Jul  3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink reflector Jul  3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink command channel Jul  3 16:29:56 disarm Keepalived_VRRP: Registering gratutious ARP shared channel Jul  3 16:29:56 disarm Keepalived_VRRP: Opening file '/usr/local/etc/keepalived.conf'. Jul  3 16:29:56 disarm Keepalived_VRRP: Configuration is using : 62990 Bytes Jul  3 16:29:57 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Transition to MASTER STATE Jul  3 16:29:58 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Entering MASTER STATE Jul  3 16:29:58 disarm Keepalived_VRRP: Netlink: skipping nl_cmd msg...

If you are unable to determine the source of a problem with the system logs, you can use tcpdump to display the VRRP advertisements that are sent on the local network. Advertisements are sent to a reserved VRRP multicast address (224.0.0.18), so the following filter can be used to display all VRRP traffic that is visible on the interface passed to the "-i" option:

$ tcpdump -vvv -n -i br0 host 224.0.0.18 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes  10:18:23.621512 IP (tos 0x0, ttl 255, id 102, offset 0, flags [none], proto VRRP (112), length 40) \                 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple,                  intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746"  10:18:25.621977 IP (tos 0x0, ttl 255, id 103, offset 0, flags [none], proto VRRP (112), length 40) \                 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple,                  intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746"                          .........

The output contains several pieces of data that be useful for debugging problems:

authtype - the type of authentication in use (authentication configuration directive) vrid - the virtual router id (virtual_router_id configuration directive) prio - the priority of the device (priority configuration directive) intvl - how often to send out advertisements (advert_int configuration directive) auth - the authentication token sent (auth_pass configuration directive)

Conclusion

In this article I described how to set up a host to use the keepalived daemon, and provided a sample configuration file that can be used to failover virtual interfaces between servers. Keepalived has a slew of options not covered here, and I will refer you to the keepalived source code and documentation for additional details

abin 2015-11-01 21:06 发表评论

Keepalived中Master和Backup角色选�D�{�略

abin — Sun, 11 Oct 2015 16:50:00 GMT

在Keepalived集群中，其实�q�没有严格意义上的主、备节点�Q�虽然可以在Keepalived配置文�g中设�|?#8220;state”选项�?#8220;MASTER”状态，但是�q��ƈ不意味着此节点一直就是Master角色。控制节点角色的是Keepalived配置文�g中的“priority”��|��但�ƈ它�ƈ不控制所有节点的角色�Q�另一个能改变节点角色的是在vrrp_script模块中设�|�的“weight”��|��q�两个选项对应的都是一个整数��|��其中“weight”值可以是个负整数�Q�一个节点在集群中的角色��是通过�q�两个值的大小军_��的�?/p>

在一个一��d��备的Keepalived集群中，“priority”值最大的��成为集��中的Master节点�Q�而其他都是Backup节点。在Master节点发生故障后，Backup节点之间��进�?#8220;民主选�D”�Q�通过对节点优先��?#8220;priority”�?#8220;“weight”的计��，选出新的Master节点接管集群服务�?/p>

在vrrp_script模块中，如果不设�|?#8220;weight”选项��|��那么集群优先�U�的选择��由Keepalived配置文�g中的“priority”值决定，而在需要对集群中优先��q�行灉|��控制�Ӟ��可以通过在vrrp_script模块中设�|?#8220;weight”值来实现。下面列举一个实例来具体说明�?/p>

假定有A和B两节点组成的Keepalived集群�Q�在A节点keepalived.conf文�g中，讄��“priority”��gؓ100�Q�而在B节点keepalived.conf文�g中，讄��“priority”��gؓ80�Q��ƈ且A、B两个节点都��用了“vrrp_script”模块来监控mysql服务�Q�同旉��讄��“weight”��gؓ10�Q�那么将会发生如下情��c�?/p>

在两节点都启动Keepalived服务后，正常情况是A节点��成为集��中的Master节点�Q�而B自动成�ؓBackup节点�Q�此时将A节点的mysql服务关闭�Q�通过查看日志发现�Q��ƈ没有出现B节点接管A节点的日志，B节点仍然处于Backup状态，而A节点依旧是Master状态，在这�U�情况下整个HA集群��失��L��义�?/p>

下面��分析一下��生这�U�情�늚�原因�Q�这也就是Keepalived集群中主、备角色选�D�{�略的问题。下面�ȝ��了在Keepalived中��用vrrp_script模块时整个集��角色的选�D��法�Q�由�?#8220;weight”值可以是正数也可以是负数�Q�因此，要分两种情况�q�行说明�?/p>

1. “weight”��gؓ正数�?/p>

在vrrp_script中指定的脚本如果��成功，那么Master节点的权值将�?#8220;weight��g��”priority“��g��和，如果脚本��失败，那么Master节点的权��g��持�ؓ“priority”��|��因此切换�{�略为：

Master节点“vrrp_script”脚本��失败时�Q�如果Master节点“priority”值小于Backup节点“weight��g��”priority“��g��和，��发生主、备切换�?/p>

Master节点“vrrp_script”脚本��成功时�Q�如果Master节点“weight”��g��“priority”��g��和大于Backup节点“weight”��g��“priority”��g��和，主节点依然�ؓ主节点，不发生切换�?/p>

2. “weight”��gؓ负数�?/p>

�?#8220;vrrp_script”中指定的脚本如果��成功，那么Master节点的权��g��?#8220;priority”��|��当脚本检��失败时�Q�Master节点的权值将�?#8220;priority“��g��“weight”��g��差，因此切换�{�略为：

Master节点“vrrp_script”脚本��失败时�Q�如果Master节点“priority”��g��“weight”��g��差小于Backup节点“priority”��|��发生主、备切换�?/p>

Master节点“vrrp_script”脚本��成功时�Q�如果Master节点“priority”值大于Backup节点“priority”值时�Q�主节点依然��Z��节点�Q�不发生切换�?/p>

在熟悉了Keepalived丅R��备角色的选�D�{�略后，再来分析一下刚才实例，�׃��A、B两个节点讄��?#8220;weight”值都�?0�Q�因此符合选�D�{�略的第一�U�，在A节点停止Mysql服务后，A节点的脚本检��将��p�|�Q�此时A节点的权值将保持为A节点上设�|�的“priority”��|��即�ؓ100�Q�而B节点的权值将变�ؓ“weight”��g��“priority”��g��和，也就�?0�Q?0+80�Q�，�q�样��出��C��A节点权��g��然大于B节点权值的情况�Q�因此不会发生主、备切换�?/p>

对于“weight”值的讄��Q�有一个简单的标准�Q�即“weight”值的�l�对��D��大于Master和Backup节点“priority”��g��差。对于上面A、B两个节点的例子，只要讄��“weight”值大�?0卛_��保证集群正常�q�行和切换。由此可见，对于“weight值的讄��Q�要非常谨慎�Q�如果设�|�不好，��导致集��角色选�D��p�|�Q��集群陷于瘫痪状态�?/p>

abin 2015-10-12 00:50 发表评论

Keepalived VS Heartbeat�Ҏ��

abin — Sun, 26 Jul 2015 12:42:00 GMT

最�q�因为项目需要，��单的试用了两��N��可用开源方案：Keepalived和Heartbeat。两者都很流行，但差异还是很大的�Q�现��试用过�E�中的感受以及相关知识点��单�ȝ��一下，供大安��择�Ҏ��的时候参考�?/div>

1�Q�Keepalived使用更简单：从安装、配�|�、��用、维护等角度上对比，Keepalived都比Heartbeat要简单得多，��其是Heartbeat2.1.4后拆分成3个子��目�Q�安装、配�|�、��用都比较复杂�Q�尤其是出问题的时候，都不知道具体是哪个子�pȝ��出问题了�Q�而Keepalived只有1个安装文件�?个配�|�文�Ӟ��配置文�g也简单很多；

2�Q�Heartbeat功能更强大：Heartbeat虽然复杂�Q�但功能更强大，配套工具更全�Q�适合做大型集��管理，而Keepalived主要用于集群倒换�Q�基本没有管理功能；

3�Q�协议不同：Keepalived使用VRRP协议�q�行通信和选�D�Q�Heartbeat使用心蟩�q�行通信和选�D�Q�Heartbeat除了走网�l�外�Q�还可以通过串口通信�Q�貌似更可靠�Q?/div>

4�Q��用方式基本类��|��如果要基于两者设计高可用�Ҏ��Q�最�l�都要根据业务需要写自定义的脚本�Q�Keepalived的脚本没有�Q何约束，随便怎么写都可以�Q�Heartbeat的脚本有�U�束�Q�即要支持service start/stop/restart�q�种方式�Q�而且Heartbeart提供了很多默认脚本，��单的�l�定ip�Q�启动apache�{�操作都已经有了�Q?/div>

使用��Q�优先��用Keepalived�Q�当Keepalived不够用的时候才选择Heartbeat

abin 2015-07-26 20:42 发表评论