TTL for backup hosts (relayd)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

TTL for backup hosts (relayd)

bernd-34
Hi,

I got some redirects configured in relayd(8) which use backup
('fallback') hosts for the case all hosts in the 'main' table are down,
e.g. due to maintenance.

So, in this case, backup hosts get enabled and show a page like "sorry,
we're down for maintenance".

This works fine; however, after the main table hosts (at least one) are
back up and running (due to checks being successful again, or
re-enabling them) sessions that went to the backup hosts don't go away.

My primary thought was that sessions to fallback hosts would be flushed
or time out as soon as the main table is active again, or at least after
$timeout (default: 600s).

Best,

Bernd

---

pf.conf:

set limit states 100000
set limit src-nodes 100000
set timeout src.track 1800
set timeout tcp.finwait 8
set timeout tcp.closing 90

set skip on lo

EXT_IFS="{ em1 vlan123 vlan456 vlan789 carp0 carp2 carp4 }"

# filter rules and anchor for ftp-proxy(8)
#anchor "ftp-proxy/*"
#pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021

pass in quick on em3 proto pfsync

# anchor for relayd(8)
anchor "relayd/*"

pass            # to establish keep-state

# By default, do not permit remote connections to X11
block in on ! lo0 proto tcp to port 6000:6010


---

relayd.conf:

interval 10
timeout 5000

# prefork 5 # only for relays
log update

host1_4="192.168.123.10"
host2_4="192.168.123.11"
host3_4="192.168.123.12"

host_cdn1_4="192.168.123.20"
host_cdn2_4="192.168.123.21"
host_cdn3_4="192.168.123.22"


# IPv4
table <http4> { $host1_4 $host2_4 $host3_4 }
table <http4_fallback> { $host_cdn1_4 $host_cdn2_4 $host_cdn3_4 }

redirect http4 {
         listen on $ext4_blabla port 80 sticky-address

         forward to <http4> port 80 check http "/node-status" digest
5aa701f6d550e8e109fb654c17cc05b11ef53bd3
         forward to <http4_fallback> port 80 check tcp
         tag HTTP4
}

---

OpenBSD 4.9 (GENERIC.MP) #819: Wed Mar  2 06:57:49 MST 2011
     
[hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2643709952 (2521MB)
avail mem = 2559311872 (2440MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f6a4000 (63 entries)
bios0: vendor Intel Corp. version "S3420GP.86B.01.00.0048.022120111423"
date 02/21/2011
bios0: Intel Corporation S3420GP
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S5
acpi0: tables DSDT FACP APIC MCFG HPET SLIT SPCR WDDT SSDT SSDT HEST
BERT ERST EINJ
acpi0: wakeup devices MRP1(S5) GRP1(S5) G2P1(S5) G2P2(S5) G2P3(S5)
G2P4(S5) MRP2(S5) MRP3(S4) MRP4(S4) EHC2(S5) PEX0(S5) PEX1(S5) PEX2(S5)
PEX3(S5) PEX4(S5) PEX6(S5) PEX7(S5) EHC1(S5) IP2P(S5) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.36 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LO
NG
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2399.97 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LO
NG
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2399.97 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LO
NG
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2399.97 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LO
NG
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 8 pa 0xfec00000, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xa0000000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (MRP1)
acpiprt2 at acpi0: bus 2 (GRP1)
acpiprt3 at acpi0: bus 3 (G2P1)
acpiprt4 at acpi0: bus 6 (G2P2)
acpiprt5 at acpi0: bus 9 (G2P3)
acpiprt6 at acpi0: bus 10 (G2P4)
acpiprt7 at acpi0: bus -1 (MRP3)
acpiprt8 at acpi0: bus 11 (PEX0)
acpiprt9 at acpi0: bus 12 (PEX4)
acpiprt10 at acpi0: bus 13 (PEX6)
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpibtn0 at acpi0: SLPB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2399 MHz: speeds: 2395, 2394, 2261, 2128,
1995, 1862, 1729, 1596, 1463, 1330, 1197 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core DMI" rev 0x11
ppb0 at pci0 dev 3 function 0 "Intel Core PCIE" rev 0x11: apic 8 int 16
(irq 10)
pci1 at ppb0 bus 1

(...)

Reply | Threaded
Open this post in threaded view
|

Re: TTL for backup hosts (relayd)

bernd-34
Am 2012-08-01 14:07, schrieb Sebastian Benoit:

> Bernd([hidden email]) on 2012.08.01 12:07:10 +0200:
>> Hi,
>>
>> I got some redirects configured in relayd(8) which use backup
>> ('fallback') hosts for the case all hosts in the 'main' table are
>> down,
>> e.g. due to maintenance.
>>
>> So, in this case, backup hosts get enabled and show a page like
>> "sorry,
>> we're down for maintenance".
>>
>> This works fine; however, after the main table hosts (at least one)
>> are
>> back up and running (due to checks being successful again, or
>> re-enabling them) sessions that went to the backup hosts don't go
>> away.
>>
>> My primary thought was that sessions to fallback hosts would be
>> flushed
>> or time out as soon as the main table is active again, or at least
>> after
>> $timeout (default: 600s).
>>
>> Best,
>>
>> Bernd
>
> Hi Bernd,
>
> you might indeed have found a bug. I'll look into it.
>
> /Benno

Hi,

I found out that this problem does *not* persist when not using
stickyness. I'll update the machines soon (not easy because under heavy
load), and check if it still happens running 5.1.

Thanks,

Bernd