LVS

From Wikitech
Jump to navigation Jump to search
Wikimedia infrastructure

Data centres and PoPs

Networking


HTTP Caching

MediaWiki

Media

Logs

Wikimedia uses LVS for balancing traffic over multiple servers, see also load balancing architecture

Overview

Diagram of LVS setup in Esams, anno 2010

We use LVS-DR, or Direct Routing. This means that only forward (incoming) traffic is balanced by the load balancer, and return traffic does not even go through the load balancer. Essentially, the LVS balancer receives traffic for a given service IP and port, selects one out of multiple "real servers", and then forwards the packet to that real server with only a modified destination MAC address. The destination servers also listen to and accept traffic for the service IP, but don't advertise it over ARP. Return traffic is simply sent directly to the gateway/router.

The LVS balancer and the real servers need to be in the same subnet for this to work.

The real servers are monitored by a Python program called Pybal. It does certain kinds of health checks to determine which servers can be used, and pools and depools them accordingly. You can follow what Pybal is doing in log file /var/log/pybal.log.

PyBal also has an integrated BGP module that Mark has written (Twisted BGP, available in the Pybal repository). This is used as a failover/high availability protocol between the LVS balancers (PyBal) and the routers. PyBal announces the LVS service IPs to the router(s) to indicate that it is alive and can serve traffic. This also removes the need to manually configure the service IPs on the active balancers. All LVS servers are now using this setup.

HOWTO (Make sure you know whether you are using Etcd or not!)

Etcd as a backend to Pybal (All of production)

In order to manage Pybal pools in Etcd use Conftool and confctl.

High level overview:

  • Define node and services in conftool-data/ in ops-puppet
  • puppet-merge and conftool-merge your change
  • Nodes will usually inherit a default pool/weight value based on their service default
  • To modify the state of the Node per service in Etcd use confctl
  • Pybal is consuming from etcd directly, using HTTP Long Polling to watch for changes in the service definition in Etcd.
  • Any change should be picked up by pybal within a very short timespan (usually, less than a second)
  • If you want to see what is currently defined on pybal, you can browse the pools under https://config-master.wikimedia.org/pybal/

Depooling servers provides examples of confctl usage. Load Balanced Services And Conftool has further details on what various states in conftool mean for LVS pools, and what helper scripts are available and their inner workings.

Planned reboot of LVS servers

  • Reboot the secondaries and verify they look sane afterwards: pybal is actually running, ipvsadm -L output looks right
  • Stop pybal on the primary
  • Stay logged into the matching secondary and confirm (dstat 10, ipvsadm -L) that traffic is coming in when pybal stops on the primary
  • Reboot the primary
  • Wait for traffic to flip-back post reboot

Planned reboots of Varnish frontends

A systemd service called traffic-pool is installed on all cpNNN machines to assist with planned reboots. This service will cause an etcd depool of all services hosted on the machine on shutdown/reboot with a 45 second pause between depool and the stop of nginx/varnish services. It will also repool when the host comes back up if /var/lib/traffic-pool/pool-once is present.

For a planned reboot, you need to execute the following commands:

touch /var/lib/traffic-pool/pool-once
reboot

Pool or depool hosts (for non-Etcd managed pools)

Edit the files in /srv/pybal-config/pybal/$colo on config-master.$colo and wait a minute - PyBal will fetch the file over HTTP. Please don't forget to commit your changes locally.

If you set a host do disabled, PyBal will continue to monitor it but just not pool it:

{ 'host': 'knsq1.esams.wikimedia.org', 'weight': 10, 'enabled': False }

If you comment the line, PyBal will forget about it completely.

Emergency situations

In emergency cases, you can do this manually using ipvsadm, if PyBal for some reason is not working for example.

ipvsadm -d -t VIP:PORT -r REALSERVER

Such as:

ipvsadm -d -t 91.198.174.232:80 -r knsq1.esams.wikimedia.org

Note that PyBal won't know about this, so make sure you bring the situation back in sync.

Example request for checking the current status for restbase in eqiad via http:

curl http://config-master.eqiad.wmnet/conftool/eqiad/restbase

See which LVS balancer is active for a given service

If you have ssh access to the host in question, sshing to the IP address will land you in a shell on whichever system is active.

 $ ssh root@ms-fe.eqiad.wmnet
 root@lvs4:~#

If you don't want to connect (or can't connect) to the system, ask the directly attached routers. You can request the route for a given service IP. E.g. on Foundry:

csw1-esams#show ip route 91.198.174.234
Type Codes - B:BGP D:Connected I:ISIS S:Static R:RIP O:OSPF; Cost - Dist/Metric
Uptime - Days:Hours:Minutes:Seconds 
        Destination        Gateway         Port        Cost     Type Uptime
1       91.198.174.234/32  91.198.174.110  ve 1        20/1     B    10:14:28:44

So 91.198.174.110 (amslvs2] is active for Upload LVS service IP 91.198.174.234.

On Juniper:

csw2-esams> show route 91.198.174.232 

inet.0: 38 destinations, 41 routes (38 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

91.198.174.232/32  *[BGP/170] 19:38:18, localpref 100, from 91.198.174.247
                      AS path: 64600 I
                    > to 91.198.174.109 via vlan.100
                    [BGP/170] 1w3d 14:24:52, MED 10, localpref 100
                      AS path: 64600 I
                    > to 91.198.174.111 via vlan.100

So 91.198.174.109 (*) is active for Text LVS service IP 91.198.174.232.

To see all LVS servers configured for a service

To see which servers are configured for a service, but not which server is currently active, look in the puppet configs.

  • configuration is stored in hieradata/common/service.yaml
  • look for your service (eg 'swift' or 'upload')
  • look for the lvs -> class entry, which will be something like low-traffic
  • back up in lvs/configuration.pp to the section defining the $lvs_class_hosts variable.
  • look for your class (eg low-traffic)
  • you should see sections for production and labs, with variables for each data center listing the lvs servers responsible.

Deploy a change to an existing service

Preconditions:

  • you have already made the change in puppet and puppet-merged it on the puppet master (puppetmaster1001.eqiad.wmnet).
  • you have tested the change on the backend real servers directly (eg if you were changing a health check URL you have already queried the backend servers for that URL successfully).

Deploy steps:

  • find out which LVS servers host your service (see above). For this example, I'll use lvs 3 and 4.
  • find out which LVS server is active (see above). For this example, I'll assume lvs4.
  • log into the inactive host twice.
  • in one session, tail the pybal log looking for one (or more) of your backend servers. eg journalctl -u pybal -f and look for errors
  • in the other session, run puppet and verify your change exists on the local filesystem
  • get a list of all IP addresses served by this LVS server - you're going to check that they all exist after your change
    • run ip addr and save the output for later
  • restart pybal:
    • systemctl stop pybal.service
    • Verify that it stopped correctly with systemctl status pybal.service
    • systemctl start pybal.service
  • check that all the expected IP addresses exist
    • run 'ip addr' and compare against the list you collected before making your change
  • in the log you're tailing, you should see a few messages like:
 2012-03-13 19:21:26.015393 New enabled server ms-fe1.pmtpa.wmnet, weight 40
 2012-03-13 19:21:26.015611 New enabled server ms-fe2.pmtpa.wmnet, weight 40
 2012-03-13 19:21:26.015666 ['-a -t 10.2.1.27:80 -r ms-fe2.pmtpa.wmnet -w 40', '-a -t 10.2.1.27:80 -r ms-fe1.pmtpa.wmnet -w 40']
  • Look for errors in the next couple of minutes!
    • example of a failed change (note that it still says enabled/up/pooled for a few lines - look for the Fetch line):
 2012-03-13 19:27:23.626787 [IdleConnection] ms-fe2.pmtpa.wmnet (enabled/up/pooled): Connection established.
 2012-03-13 19:27:23.632928 [IdleConnection] ms-fe1.pmtpa.wmnet (enabled/up/pooled): Connection established.
 2012-03-13 19:27:33.555879 [ProxyFetch] ms-fe2.pmtpa.wmnet (enabled/up/pooled): Fetch failed, 0.005 s
 2012-03-13 19:27:33.555917 Monitoring instance ProxyFetch reports servers ms-fe2.pmtpa.wmnet (enabled/up/pooled) down: 404 Not Found
 2012-03-13 19:27:33.556022 ['-d -t 10.2.1.27:80 -r ms-fe2.pmtpa.wmnet']
 2012-03-13 19:27:33.562458 [ProxyFetch] ms-fe1.pmtpa.wmnet (enabled/up/pooled): Fetch failed, 0.012 s
 2012-03-13 19:27:33.562533 Monitoring instance ProxyFetch reports servers ms-fe1.pmtpa.wmnet (enabled/up/pooled) down: 404 Not Found
 2012-03-13 19:27:33.562589 Could not depool server ms-fe1.pmtpa.wmnet because of too many down!
 2012-03-13 19:27:43.561745 [ProxyFetch] ms-fe2.pmtpa.wmnet (enabled/partially up/not pooled): Fetch failed, 0.002 s
 2012-03-13 19:27:43.565608 [ProxyFetch] ms-fe1.pmtpa.wmnet (enabled/partially up/pooled): Fetch failed, 0.003 s
  • if your change was successful, repeat the procedure on the active host.
    • when you stop pybal on the active host, traffic will immediately fail over to the standby host.
    • when you restart pybal on the formerly active host, traffic will immediately fail back (the LVS pairs are configured with a default and a standby so traffic always flows to the default if it's up).
  • You can check the status of your service pool at any time by fetching http://localhost:9090/pools/<pool-name
  • Example output:
lvs1002 $ curl localhost:9090/pools 
streamlb_80 
dns_rec_53 
...
lvs1002 $ curl localhost:9090/pools/dns_rec_53 
chromium.wikimedia.org:	enabled/up/pooled 
hydrogen.wikimedia.org:	enabled/up/pooled

Add a new load balanced service

A service can be either high-traffic (public-facing) or low-traffic ("internal" services, which also means traffic from the CDN edge proxies to any backend, e.g. Mediawiki appservers). Yes, the naming is bad.

There are different phases to adding a load-balanced service, that can be logically summarized as follow:

  1. Ensure the service is running on all the backend servers
  2. Add relevant data in etcd
  3. Add DNS records, allocate service IPs in all datacenters where the service is running
  4. Create an entry in the service::catalog
  5. Add this IP to the loopback interface on all the servers where the service is present
  6. Configure the load balancers to provide balancing across those backends
  7. Add Icinga monitoring of those balanced services
  8. Make the monitoring page, add the puppet-generated discovery DNS resources
  9. Add discovery DNS records for the service

These logical steps translate to a series of steps to perform across the operations/dns and the operations/puppet repositories.

Let's go through all of them – minus setting up the backends running the service, which we'll assume you have already done. Please note the procedure below is optimized for reducing manual intervention and for avoiding the "oops new service, disregard" pages.

A quick note about SSL/TLS

In ancient times, almost no services were TLS-enabled. Then there was a transition period as part of the switch to ATS where more and more services exposed a TLS endpoint in addition to their standard cleartext HTTP one (which required configuring a new LVS service). If you're defining a new service, don't be led astray by this: just create a single, TLS-enabled service. Use Envoy for the TLS terminator (in Puppet, you can use profile::tlsproxy::envoy).

Add data in etcd

etcd data for backend selection

You need to add the relevant data in conftool-data for adding your new service to the servers where it's running.

So for instance, if you're adding service foo to servers srv* part of the bar cluster in eqiad, you'll need something like:

# File: node/eqiad.yaml
eqiad:
   bar:
     srv1: [foo]
     srv2: [foo]
...

Please note this will add the service with status pooled: inactive, weight: 0. You will need to set pooled status and weight with confctl.

Following up on our example:

$ sudo confctl select 'cluster=bar,service=foo' set/pooled=yes:weight=1
etcd data for DNS Discovery

You will also need to add your service to the discovery objects. So in our case, to conftool-data/discovery/services.yaml

foo: [eqiad,codfw]

DNS changes

  • allocate an IP address per colo to serve your content
  • internal addresses should have names *.svc.$colo.wmnet:
    • codfw should be in the 10.2.1.0/24 range
    • eqiad should be in the 10.2.2.0/24 range
  • external addresses:
    • These need to be allocated from the (small!) public IP address pool, and may need specific configuration on the routers. Talk to the network admins first (Arzhel/Brandon/Mark/Faidon).
  • Examples:
    • eventgate-analytics.svc.eqiad.wmnet
    • eventgate-analytics.svc.codfw.wmnet

Create an entry in the service::catalog

In hiera, under hieradata/common/service.yaml there is an entry called service::catalog. This data structure contains the full definition of your service, as far as puppet is concerned – the configuration of LVS and of monitoring is derived from the definition here. Here is a full entry you can model yours around:

service::catalog:
  echostore:
    description: Echo store, echostore.svc.%{::site}.wmnet
    encryption: true # If the service offers TLS encryption or not
    ip: # Hash of site: list of IPs with a label. If you have only one IP, use "default"
      codfw:
        default: 10.2.1.49
      eqiad:
        default: 10.2.2.49
    lvs: # Properties that are related to LVS setup.
      class: low-traffic
      conftool: # any service on k8s should re-use this same definition. Other services should use their own values.
        cluster: kubernetes
        service: kubesvc
      depool_threshold: '.5'
      enabled: true
      monitors:
        IdleConnection:
          max-delay: 300
          timeout-clean-reconnect: 3
        ProxyFetch:
          url:
          - https://localhost/healthz
      scheduler: wrr
      protocol: tcp
    monitoring: # Optional entries for monitoring the service
      check_command: check_https_port_status!8082!200!/healthz # command for the check in icinga
      critical: false # failures page if true
      sites: # hostnames to perform the checks for. Every site should have its own host.
        codfw:
          hostname: echostore.svc.codfw.wmnet
        eqiad:
          hostname: echostore.svc.eqiad.wmnet
    port: 8082  # for k8s services, choose based on https://wikitech.wikimedia.org/wiki/Service_ports
    sites:
    - eqiad
    - codfw
    state: service_setup # this is the most important entry in your service definition! See below for details
    discovery: # Discovery DNS configuration. You can have multiple entries for a single service.
    - dnsdisc: echostore
      active_active: true
The supported state transitions for state parameter

Here we've defined state to be "service_setup"; this means that this service will not be included in monitoring, LVS configuration, or DNS Discovery at the moment. Until you perform the next step in the procedure, adding this stanza will be a no-op.

For k8s services, choose a port number based on the table at Service ports.

Add the IPs on the backend servers

If you aren't using Kubernetes, and the puppet role on your backend servers doesn't already include profile::lvs::realserver, add it. Once that profile is included, you'll also need to add a hiera configuration as follows:

profile::lvs::realserver::pools:
  echostore: {}

Use the same label you used in service::catalog. Once puppet runs on the backends, the LVS ip will be configured on their loopback device, allowing them to respond to traffic directed to the LVS service.

Configure the load balancers

To add the configuration to pybal and add the LVS endpoint on the load-balancers, you just need to change the state of your service to lvs_setup. Once puppet has run on the LVS servers, you will have to restart pybal for your changes to take effect. Restarting pybal requires some care - follow this procedure:

  1. Check in with #wikimedia-traffic connect that your change looks good and that now is a good time for a PyBal restart.
  2. Run puppet on all LVS servers
    • sudo cumin 'O:lvs::balancer' 'run-puppet-agent'
  3. Ask on #wikimedia-traffic which are the backup LVS server for the LVS class of your service on both datacentres and restart pybal just on those
  4. Run a test
    • Example http://eventgate-analytics.svc.eqiad.wmnet:31192/_info
  5. Wait 120 secs
  6. Restart pybal on the active LVS server, ask #wikimedia-traffic

Add monitoring to the load-balanced services

Just change the state of your service from lvs_setup to monitoring_setup, then run puppet on the icinga hosts.

  sudo cumin 'A:icinga' 'run-puppet-agent'

Wait until the new checks is configured and green in the icinga UI. (In our case above, the host "echostore.svc.codfw.wmnet" will have two Icinga service checks named "Echo store, echostore.svc.codfw.wmnet IPv4" and "... IPv6", although not all configurations will have IPv6.)

Make the service page, add discovery resources

Change the state of your service to production, then run puppet on the icinga server. Also run puppet on the auth dns servers, which will add DNS discovery entries for your service to the zones they serve:

$ sudo cumin 'A:icinga or A:dns-auth' run-puppet-agent

Add the dns discovery record

What you need to do depends on the nature of your service.

For active/active services

If you declared active_active = true

  1. Add discovery entries to templates/wmnet in operations/dns. Your entry should be of the geoip type. Also add an entry to utils/mock_etc/discovery-geo-resources. See for instance this change
  2. Pool both datacenters in confctl
$ confctl --object-type discovery select 'dnsdisc=echostore' set/pooled=true
For active/passive services

If you have an active/passive service instead (i.e. you declared active_active = false):

  1. Add discovery entries to templates/wmnet in operations/dns. Your entry should be of the ,etafp type. Also add an entry to utils/mock_etc/discovery-metafo-resources. See for instance this change
  2. Pool one datacenter in confctl
$ confctl --object-type discovery select 'name=eqiad,dnsdisc=echostore' set/pooled=true

Make sure the other datacenters are not pooled:

$ confctl --object-type discovery select 'dnsdisc=echostore' get
For both active/active and active/passive:
  1. Merge the DNS change. Choose one authoritative DNS (eg: authdns1001.wikimedia.org), and run sudo -i authdns-update. That script will deploy your change to all our DNS servers.


You're done! Your service will be now correctly configured to work in production.

Remove a load balanced service

The procedure for removal of a service should more or less follow the inverse order of what gets done adding it. Specifically:

  1. Remove the discovery DNS record
  2. Remove monitoring from Icinga
  3. Remove the service from the load-balancers and the backend servers
  4. Remove conftool data for both the lvs pool and dns discovery
  5. Remove entry from service::catalog

Remove the discovery DNS record

Simply remove the entry from the operations/dns repository:

  1. Remove the entry from templates/wmnet
  2. Remove it from the relevant files under utils/mock_etc/
  3. Merge the DNS change. Choose one authoritative DNS (eg: authdns1001.wikimedia.org), and run sudo -i authdns-update

Remove monitoring in icinga

To remove monitoring in icinga and the discovery templates from the dns servers, just change state: production to state: lvs_setup, then run puppet on the icinga servers and the auth dns ones.

$ sudo cumin 'A:icinga or A:dns-auth' run-puppet-agent

Remove the service from the load-balancers and the backend servers

Change state: lvs_setup to state: service_setup, and remove the service stanza from profile::lvs::realserver::pools. Then:

  1. Run puppet on all LVS servers
    • cumin 'O:lvs::balancer' 'run-puppet-agent'
  2. Ask on #wikimedia-traffic which are the backup LVS server for the LVS class of your service on both datacentres and restart pybal on those
  3. Run a test
    • Example http://eventgate-analytics.svc.eqiad.wmnet:31192/_info
  4. Wait 300 secs
  5. Restart pybal on the active LVS server, ask #wikimedia-traffic
  6. Run puppet on the backends.

Final removal

You can now remove the service stanza from service::catalog, and all the references to the service inside conftool-data safely. When you merge the puppet change, your service will be successfully removed from production.

LVS installation

LVS now uses Puppet and automatic BGP failover. Puppet arranges the service IP configuration, and installation of packages. To configure the service IPs that an LVS balancer should serve (both primary and backup!), set the $lvs_balancer_ips variable:

node /amslvs[1-4]\.esams\.wikimedia\.org/ {
        $cluster = "misc_esams"

        $lvs_balancer_ips = [ "91.198.174.2", "91.198.174.232", "91.198.174.233", "91.198.174.234" ]

        include base,
                lvs::balancer
}

In this setup, all 4 hosts amslvs1-amslvs4 are configured to accept all service IPs, although in practice every service IP is only ever serviced by one out of two hosts due to the router configuration.

Puppet uses the (now misleadingly named) wikimedia-lvs-realserver package to bind these IPs to the loopback (!) interface. This is to make sure that a server answers on these IPs, but does not announce them via ARP - we'll use BGP for that.

LVS service configuration

In file lvs.pp the services themselves are configured, from which the PyBal configuration file /etc/pybal/pybal.conf is generated by Puppet.

Most configuration is in a large associative hash, $lvs_services. Each key in this hash is the name of one LVS service, and points to hash of PyBal configuration variables:

description 
Textual description of the LVS service.
class 
The class the LVS service belongs too; i.e. on which LVS balancers it is active (see below).
ip 
A hash of service IP address for the service. All IP addresses are aliases, and are translated to separate LVS services in PyBal.conf, but with identical configuration.

The other configuration variables are described in the PyBal article.

Global PyBal configuration options can be specified in the $pybal hash.

Classes

To determine which LVS services are active on which hosts, the $lvs_class_hosts determines for each class, which hosts should have the services for that class. This is used by the pybal.conf template to generate the LVS services. The following classes are used, to distribute traffic over the LVS balancer hosts:

  • high-traffic1 (text, bits)
  • high-traffic2 (text, upload)
  • https (HTTPS services corresponding to the 'high-traffic' HTTP services; should be active on all hosts that carry either class)
  • specials (special LVS services, especially those that do not have BGP enabled)
  • low-traffic (internal load balancing, e.g. from the Squids to the Apaches)

BGP failover and load sharing

Previously, the LVS balancer that had a certain service IP bound to its eth0 interface was active for that IP. To do failovers, the IP had to be moved manually.

In the new setup, multiple servers announce the service IP(s) via BGP to the router(s), which then pick which server(s) to use based on BGP routing policy.

PyBal BGP configuration

In the global section, the following BGP related settings typically exist:

bgp = yes

Enables bgp globally, but can be overridden per service.

bgp-local-asn =  64600

The ASN to use while communicating to the routers. All prefixes will get this ASN as AS path.

bgp-peer-address = 91.198.174.247

The IP of the router this PyBal instance speaks BGP to.

#bgp-as-path = 64600 64601

An optional modified AS path. Can be used e.g. to make the AS path longer and thus less attractive (on a backup balancer).

Example BGP configuration for Juniper (cr1-esams)

mark@cr1-esams> show configuration protocols bgp group PyBal 
type external;
multihop {
    ttl 2;
}
local-address 91.198.174.245;
hold-time 30;
import LVS_import;
family inet {
    unicast {
        prefix-limit {
            maximum 50;
            teardown;
        }
    }
}
family inet6 {
    unicast {
        prefix-limit {
            maximum 50;
            teardown;
        }
    }
}
export NONE;
peer-as 64600;
neighbor 91.198.174.109;
neighbor 91.198.174.110;

mark@cr1-esams> show configuration policy-options prefix-list LVS-service-ips            
10.2.0.0/16;
91.198.174.224/28;

mark@cr1-esams> show configuration policy-options prefix-list LVS-service-ips6   
2620:0:862:ed1a::/64;

mark@cr1-esams> show configuration routing-options aggregate                               
route 91.198.174.224/28;
route 10.2.3.0/24;

mark@cr1-esams> show configuration routing-options rib inet6.0 aggregate 
route 2620:0:862:ed1a::/64;

mark@cr1-esams> show configuration policy-options policy-statement ospf_export 
term 1 {
    from protocol direct;
    then accept;
}
term statics {
    from protocol [ static aggregate ];
    then accept;
}
then reject;

The LVS_import policy adds metric 10 to the "routes" (service IPs) received from the secondary (backup) LVS balancers. This means that the router will regard them as less preferred.

The individual /32 and /128 service IPs are announced by PyBal and exchanged between the routers using IBGP. Aggregates for the service IP ranges are generated by the core routers and redistributed into OSPF as well.

SSH checking

As the Apache cluster is often suffering from broken disks which break SSH but keep Apache up, I have implemented a RunCommand monitor in PyBal which can periodically run an arbitrary command, and check the server's health by the return code. If the command does not return within a certain timeout, the server is marked down as well.

The RunCommand configuration is in /etc/pybal/pybal.conf:

runcommand.command = /bin/sh
runcommand.arguments = [ '/etc/pybal/runcommand/check-apache', server.host ]
runcommand.interval = 60
runcommand.timeout = 10
runcommand.command 
The path to the command which is being run. Since we are using a shell script and PyBal does not invoke a shell by itself, we have to do that explicitly.
runcommand.arguments 
A (Python) list of command arguments. This list can refer to the monitor's server object, as shown here.
runcommand.interval 
How often to run the check (seconds).
runcommand.timeout 
The command timeout; after this amount of seconds the entire process group of the command will be KILLed, and the server is marked down.

Currently we're using the following RunCommand script, in /etc/pybal/runcommand/check-apache:

#!/bin/sh

set -e

HOST=$1
SSH_USER=pybal-check
SSH_OPTIONS="-o PasswordAuthentication=no -o StrictHostKeyChecking=no -o ConnectTimeout=8"

# Open an SSH connection to the real-server. The command is overridden by the authorized_keys file.
ssh -i /root/.ssh/pybal-check $SSH_OPTIONS $SSH_USER@$HOST true

exit 0

The limited ssh accounts on the application servers are managed by the wikimedia-task-appserver package.

Monitoring

Nagios monitoring of LVS services is managed by Puppet as well, at the bottom of the lvs.pp file. For example:

monitor_service_lvs_http { "wikimedia-lb.pmtpa.wikimedia.org":
    ip_address => "208.80.152.200",
    check_command => "check_http_lvs!meta.wikimedia.org!/wiki/Main_Page"
}
monitor_service_lvs_https { "wikimedia-lb.pmtpa.wikimedia.org":
    ip_address => "208.80.152.200",
    check_command => "check_https_url!meta.wikimedia.org!/wiki/Main_Page"
}

Diagnosing problems

Run ipvsadm -l on the director. Healthy output looks like this:

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  upload.pmtpa.wikimedia.org:h wlc
  -> sq10.pmtpa.wmnet:http        Route   10     5202       5295
  -> sq1.pmtpa.wmnet:http         Route   10     8183       12213
  -> sq4.pmtpa.wmnet:http         Route   10     7824       13360
  -> sq5.pmtpa.wmnet:http         Route   10     7843       12936
  -> sq6.pmtpa.wmnet:http         Route   10     7930       12769
  -> sq8.pmtpa.wmnet:http         Route   10     7955       11010
  -> sq2.pmtpa.wmnet:http         Route   10     7987       13190
  -> sq7.pmtpa.wmnet:http         Route   10     8003       7953

All the servers are getting a decent amount of traffic, there's just normal variation.

If a realserver is refusing connections or doesn't have the VIP configured, it will look like this:

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  upload.pmtpa.wikimedia.org:h wlc
  -> sq10.pmtpa.wmnet:http        Route   10     2          151577
  -> sq1.pmtpa.wmnet:http         Route   10     2497       1014
  -> sq4.pmtpa.wmnet:http         Route   10     2459       1047
  -> sq5.pmtpa.wmnet:http         Route   10     2389       1048
  -> sq6.pmtpa.wmnet:http         Route   10     2429       1123
  -> sq8.pmtpa.wmnet:http         Route   10     2416       1024
  -> sq2.pmtpa.wmnet:http         Route   10     2389       970
  -> sq7.pmtpa.wmnet:http         Route   10     2457       1008

Active connections for the problem server are depressed, inactive connections normal or above normal. This problem must be fixed immediately, because in wlc mode, LVS load balances based on the ActiveConn column, meaning that servers that are down get all the traffic.

Incorrectly bound interfaces

Don't ever bind IP addresses directly to lo in /etc/network/interfaces. If you do, stuff breaks. (This applies not just to LVS servers but any real server as well. Anything with the wikimedia-lvs-realserver package will break if you bind addresses manually.)

When it's broken, it looks like this. Notice that all the balanced IP addresses are tagged lo:LVS except 10.2.1.13. 13 is broken and causes the ifup script that reloads the IPs to be broken.

    inet 127.0.0.1/8 scope host lo
    inet 10.2.1.13/32 scope global lo
    inet 10.2.1.1/32 scope global lo:LVS
    inet 10.2.1.11/32 scope global lo:LVS
    inet 10.2.1.12/32 scope global lo:LVS
    inet6 ::1/128 scope host 

The solution here is to delete the broken interface (ip addr del 10.2.1.13/32 dev lo), then run dpkg-reconfigure wikimedia-lvs-realserver. This triggers the scripts that will re-add all the IP addresses.

Happy ip addr output looks like this:

root@lvs4:/etc/network# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 10.2.1.1/32 scope global lo:LVS
    inet 10.2.1.11/32 scope global lo:LVS
    inet 10.2.1.12/32 scope global lo:LVS
    inet 10.2.1.13/32 scope global lo:LVS
    inet 10.2.1.21/32 scope global lo:LVS
    inet 10.2.1.22/32 scope global lo:LVS
    inet 10.2.1.27/32 scope global lo:LVS
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    etc...