1336017121 M * Bertl off to bed now .. have a good one everyone!
1336017127 N * Bertl Bertl_zZ
1336018430 N * ensc Guest373
1336018440 J * ensc ~irc-ensc@p54ADE17F.dip.t-dialin.net
1336018849 Q * Guest373 Ping timeout: 480 seconds
1336022928 Q * quasisane Remote host closed the connection
1336024090 J * ghislain ~AQUEOS@adsl1.aqueos.com
1336024620 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1336027390 J * petzsch ~markus@dslb-088-075-172-224.pools.arcor-ip.net
1336029765 J * quasisane ~sanep@c-24-218-184-186.hsd1.nh.comcast.net
1336032574 Q * AndrewLee Ping timeout: 480 seconds
1336034013 J * clopez ~clopez@fanzine.igalia.com
1336038067 Q * ntrs Ping timeout: 480 seconds
1336038515 J * ntrs ~ntrs@vault08.rosehosting.com
1336041153 N * Bertl_zZ Bertl
1336041158 M * Bertl morning folks!
1336041665 Q * petzsch Quit: Leaving.
1336042109 J * fisted_ ~fisted@xdsl-87-78-12-17.netcologne.de
1336042359 Q * fisted Read error: Connection reset by peer
1336043290 J * Bl4ckB1rD 4d6f0224@ircip2.mibbit.com
1336043302 M * Bl4ckB1rD hello everyone
1336043311 M * pmjdebruijn lo
1336043315 M * Bl4ckB1rD one question about networking and vserver...
1336043460 M * Bertl if you have one, shoot, if you want one, I can probably give you one :)
1336043488 M * Bl4ckB1rD :)) great
1336043499 M * Bl4ckB1rD one second to explain everything in one shot :)
1336043536 M * Bertl no problem, take your time
1336043613 M * Bl4ckB1rD i've got loadbalancer that uses keepalived to loadbalance between 2 other servers that have couple of vservers. We have 2 different types of vservers, frontend and database servers. Frontend connects to databases through loadbalancer. The problem is, if frontend server and database server are on the same server, host see's dummy0 address, and if database 
1336043626 M * Bl4ckB1rD server on same host is down, it doesn't use loadbalancer
1336043658 M * Bl4ckB1rD is there a way to "hide" these dummy0 address from database server...  to force him to use loadbalancer while connecting 
1336043676 M * Bl4ckB1rD i hope you understand , otherwise i'll just draw it and post link to image
1336043725 M * Bl4ckB1rD the thing is, host knows for this dummy0 address that is used only for loadbalancing... (we have direct routing loadbalancing in this case)
1336043834 M * Bl4ckB1rD and it forces frontend vserver to use database vserver located on same server.
1336043844 M * Bl4ckB1rD even if particular vserver is down
1336043937 M * Bl4ckB1rD it's problem cause we can't use frontend vservers located on same machine as database that has maintenance going on, cause they keep trying to connect to it's dummy address which is on same interface and doesn't use loadbalancer's real ip, which then connects to particular dummy address and balances databases.
1336043996 M * Bl4ckB1rD frontend has only readings which means we can balance databases that way.
1336044014 Q * ensc|w Remote host closed the connection
1336044023 J * ensc|w ~ensc@www.sigma-chemnitz.de
1336044725 M * Bertl well, first, the dummy0 is yor choice
1336044748 M * Bertl i.e. there is no reason to use dummy0, you can as well use eth0, ath0 or whatever interface you have
1336044759 M * Bertl (i.e. it doesn't matter to Linux-VServer)
1336044774 M * Bertl but, that is not really related to your problem I guess
1336044823 M * Bertl which probably is more that all IPs on a host system are considered 'local' (by default, there are tricks to change that) and thus traffic will use 'lo' anyway
1336044836 M * Bl4ckB1rD yes
1336044839 M * Bl4ckB1rD exactly
1336044860 M * Bertl now, one way to 'force' the load balancer even for local traffic is to make it non-local
1336044872 M * Bl4ckB1rD aha...
1336044879 M * Bertl e.g. by doing some address translation to an external (load balancer) address for example
1336044922 M * Bertl another one is to override the routing tables for thos 'local' IPs so that they get routed to the balancer instead
1336044931 M * Bl4ckB1rD yes yes
1336044946 M * Bl4ckB1rD but... 
1336044946 M * Bertl both has a great potential to confuse the hell out of your infrastructure :)
1336044950 M * Bl4ckB1rD yes :D
1336044958 M * Bl4ckB1rD i can imagine
1336044958 M * Bl4ckB1rD :D
1336044975 M * Bl4ckB1rD the other option is to split frontend and put backend servers on servers that dont have frontend on it :)
1336044997 M * Bertl yes, for example, if that is 'just' a service time case
1336045009 M * Bertl you could simply put one of them into a kvm guest
1336045016 M * Bl4ckB1rD hmm
1336045036 M * Bertl basically a copy of the host system, with a Linux-VServer kernel
1336045054 M * Bertl or, alternatively you could utilize network namespaces
1336045071 M * Bertl and create a separate setup for each guest group
1336045113 M * Bl4ckB1rD well the main thing that bothers me is that if i have really hardcore server with 20+ cpu's , sas disks and everything, and i put 2 frontend and 1 backend vserver on it, i loose both frontend servers while i put down the backend vserver for maintenance ...  but okay... 
1336045138 M * Bl4ckB1rD i see
1336045175 M * Bertl vserver = guest?
1336045179 M * Bl4ckB1rD yes
1336045193 M * Bertl so what is the maintainance needed there?
1336045218 M * Bl4ckB1rD well currently i had to copy database from raid10 store to raid0 and database had to be put down to do that...
1336045220 M * Bertl I was more thinking that you meant maintainance on the host system
1336045260 M * Bl4ckB1rD and the alerts started to pop in that we have problems on frontend servers accessing database... even though that other 2 mysql servers were online and could be used
1336045264 M * Bertl okay, so you have a bunch of physical servers (hosts in our terminology)
1336045272 M * Bl4ckB1rD naah, maintenance on particular guest
1336045284 M * Bl4ckB1rD yes 
1336045288 M * Bl4ckB1rD i have like 10 hosts
1336045291 M * Bertl and usually you separate the guests (frontends and backends)
1336045292 M * Bl4ckB1rD and like 130 vservers...
1336045294 M * Bl4ckB1rD -.-
1336045297 M * Bl4ckB1rD i mean guests
1336045310 M * Bl4ckB1rD well yes
1336045318 M * Bl4ckB1rD i separate frontend and databases
1336045324 M * Bertl okay
1336045344 M * Bertl so what is the reason to put them togethen when you do maintainance work on one guest?
1336045356 M * Bl4ckB1rD so that each server does it's own purpose and all of them are the same
1336045366 M * Bl4ckB1rD for example, frontends are same , and databases are same
1336045378 Q * Aiken Remote host closed the connection
1336045389 M * Bertl yes, makes sense to me, still I do not see a reason to put them on the same host?
1336045419 M * Bl4ckB1rD umm ?! to separate different types of servers ?
1336045424 M * Bertl let's say you have 20 database guests and 100 frontend guests
1336045427 M * Bl4ckB1rD yes
1336045430 M * Bl4ckB1rD and 10 hosts
1336045434 M * Bertl yes
1336045451 M * Bl4ckB1rD i have let's say 5 database servers connected together with replication
1336045471 M * Bl4ckB1rD and 20 frontend servers connect to them through loadbalancer
1336045476 M * Bl4ckB1rD that balances between those 5
1336045484 M * Bertl okay, sounds good
1336045497 M * Bl4ckB1rD but some frontend servers reside on same host as a database of course
1336045502 M * Bertl why?
1336045522 M * Bl4ckB1rD cause frontend does cpu usage, and databases are io bound...
1336045529 M * Bl4ckB1rD to make most of the computer...
1336045532 M * Bl4ckB1rD i guess
1336045546 M * Bl4ckB1rD why wouldn't it be on same host ?
1336045575 M * Bl4ckB1rD i would need another rack with like 10 hosts more to put same infrastructure on it and separate databases from frontends :)
1336045583 M * Bl4ckB1rD physically
1336045584 M * Bl4ckB1rD :D
1336045586 M * Bertl that's fine, but the main question is, why do the frontends on that host need to connect to that specific databas (on the same host)?
1336045603 M * Bertl *database
1336045628 M * Bl4ckB1rD they need to connect through loadbalancer... but they dont... to get data to serve to customers that data...
1336045642 M * Bl4ckB1rD i dont understand your question actually
1336045644 M * Bl4ckB1rD ;)
1336045656 M * Bertl well, I presume the 5 database guests are somewhat redundant
1336045663 M * Bl4ckB1rD yes
1336045669 M * Bl4ckB1rD if one goes down
1336045669 M * Bertl i.e. any frontend can connect to any of those
1336045673 M * Bl4ckB1rD the other 4 still work
1336045675 M * Bl4ckB1rD yes
1336045676 M * Bl4ckB1rD exactly
1336045695 M * Bertl so, to do that, you need to have a separate IP for the balancer
1336045713 M * Bertl i.e. you connect to the balancer IP and it gets redirected to any of those databases
1336045723 M * Bl4ckB1rD but those 2 frontends on the same host as the "maintenanced" database dont connect to them and want to connect to the one that is down -.-
1336045734 M * Bl4ckB1rD yes
1336045737 M * Bl4ckB1rD exactly
1336045742 M * Bl4ckB1rD i have that
1336045748 M * Bl4ckB1rD but if you have direct routing
1336045754 M * Bertl the balancer is external to the setup, no?
1336045758 M * Bl4ckB1rD yes
1336045763 M * Bl4ckB1rD totally external
1336045788 M * Bertl so, why should the host use the 'direct' route unless somehow instructed by the load balancer
1336045804 M * Bertl i.e. the balancer IP is definitely not local to any of the hosts
1336045816 M * Bertl and the database IPs are not local to the balancer
1336045848 M * Bertl so unless the balancer does some hand off (what is probably yor problem)
1336045858 M * Bertl there should be no issues with this setup
1336045879 M * Bertl for the hand off part, the balancer could simply avoid the same host
1336045908 M * Bertl i.e. if the guest is on the same host/range as the database, just don't use it
1336046007 M * Bl4ckB1rD the thing is
1336046014 M * Bl4ckB1rD loadbalancer has VRRP
1336046016 M * Bl4ckB1rD vip
1336046018 M * Bl4ckB1rD virtual ip
1336046038 M * Bl4ckB1rD and server like database
1336046045 M * Bl4ckB1rD has to have this virtual ip as non-arp
1336046053 M * Bl4ckB1rD cause that's how direct routing works ...
1336046084 M * Bl4ckB1rD and if each database has this dummy "virtual ip" means there are like 5 servers with same ip
1336046093 M * Bl4ckB1rD but no arp not to have conflict
1336046095 M * Bl4ckB1rD on the network
1336046119 M * Bertl yup
1336046120 M * Bl4ckB1rD and of course when frontend wants to connect to loadbalancer... it see's this dummy address on it's own interface
1336046127 M * Bl4ckB1rD from one of the guests
1336046130 M * Bl4ckB1rD and answers on it
1336046132 M * Bl4ckB1rD -.-
1336046139 M * Bl4ckB1rD even if it's not rly up
1336046144 M * Bl4ckB1rD maybe i should stop the vserver
1336046145 M * Bl4ckB1rD totally
1336046147 M * Bl4ckB1rD to avoid this
1336046161 M * Bl4ckB1rD cause this time i let guest running
1336046163 J * Fire_Egl ~FireEgl@173-16-9-169.client.mchsi.com
1336046164 M * Bl4ckB1rD and only stopped services
1336046170 M * Bl4ckB1rD if i shutdown the server
1336046176 M * Bl4ckB1rD so it wouldn't listen on same interface...
1336046179 M * Bl4ckB1rD anymore
1336046190 M * Bl4ckB1rD maybe it would go through loadbalancer then
1336046193 M * Bl4ckB1rD what do you think
1336046201 M * Bertl well, depending on your config, the IP is brought up/down by util-vserver
1336046237 Q * FireEgl Ping timeout: 480 seconds
1336046250 M * Bertl so, yes, it might help, but I still think you have a design problem there
1336046289 M * Bl4ckB1rD design in what way ?
1336046313 M * Bl4ckB1rD that direct routing is wrong ?
1336046321 M * Bertl let's use a simplified example and actual IPs
1336046327 M * Bl4ckB1rD okay
1336046343 M * Bl4ckB1rD thanks for your time btw
1336046343 M * Bertl let's say the database VIP is 192.168.1.1
1336046344 M * Bl4ckB1rD :)
1336046348 M * Bl4ckB1rD yes
1336046361 M * Bertl now, I presume you put that IP on each host
1336046371 M * Bl4ckB1rD yes
1336046372 M * Bl4ckB1rD as dummy
1336046378 M * Bertl let's assume you have 2 hosts
1336046383 M * Bl4ckB1rD yes
1336046388 M * Bl4ckB1rD hosts, not guests ?
1336046393 M * Bertl and they carry a number of guests using 192.168.0.x IPs
1336046403 M * Bl4ckB1rD okay
1336046413 M * Bertl so we have, for example 192.168.0.1/2/3 on host A
1336046428 M * Bertl and 192.168.0.4/5 on host B
1336046433 M * Bl4ckB1rD sure
1336046433 M * Bl4ckB1rD okay
1336046459 M * Bertl now when you try to reach the database via 192.168.1.1, that IP is of course local
1336046466 M * Bl4ckB1rD yes
1336046485 M * Bl4ckB1rD cause both hosts have this vip as "dummy"
1336046495 M * Bertl so, options are:
1336046516 M * Bertl 1) mess with routing tables to make it non-local (works to some extend)
1336046539 M * Bertl 2) do prerouting nat to an external IP, e.g. 192.168.1.2
1336046545 M * Bl4ckB1rD wouldn't want to do that... since that can crash whole network -.-
1336046560 M * Bl4ckB1rD aha...
1336046565 M * Bertl  in this case, the load balancer or each host has to undo that
1336046609 M * Bl4ckB1rD i understand...
1336046614 M * Bertl 3) use separate IPs for each database and a smart balancer
1336046628 M * Bertl   that one has to pick the correct database for each guest
1336046633 M * Bl4ckB1rD first 2 seem like really messy shit
1336046646 M * Bertl and finally:
1336046673 M * Bertl 4) be fine with local connections, just make sure the IPs are not there when the database is down
1336046724 M * Bl4ckB1rD one question more
1336046728 M * Bl4ckB1rD smart balancer 
1336046731 M * Bl4ckB1rD what would that be ?
1336046737 M * Bl4ckB1rD i assume not keepalived
1336046748 M * Bl4ckB1rD but some software based balancing
1336046769 M * Bl4ckB1rD meaning frontend should know about the ip's of databases and use them accordingly
1336046780 M * Bl4ckB1rD if i understand correctly
1336046783 M * Bertl well, doesn't strictly need software based balancing, but it definitely needs dynamic rules
1336046855 M * Bl4ckB1rD thank you very much for these detailed infromation
1336046862 M * Bertl you're welcome!
1336046874 M * Bl4ckB1rD thank you for your time
1336046923 J * AndrewLee ~andrew@210.240.39.201
1336046927 M * Bertl if you feel like it, there is a donations page :)
1336046929 M * Bl4ckB1rD i think i'll go with last option as it seems fine for my situation. I use own vip for each service which means it can be simply put down on any host.
1336046959 M * Bl4ckB1rD i'll have in mind
1336046995 M * Bertl yes, I think that would probably be the easiest solution at least for a small/maintainable number of host/guests
1336047011 M * Bl4ckB1rD true.
1336047046 M * Bl4ckB1rD thanks 
1336047578 M * Bertl np
1336048746 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com
1336051442 Q * BenG Quit: I Leave
1336051667 J * derjohn_mob ~aj@87.253.171.221
1336054407 M * Bertl off for a nap ... bbl
1336054419 M * Bl4ckB1rD bye bye
1336054420 N * Bertl Bertl_zZ
1336057501 J * dowdle ~dowdle@scott.coe.montana.edu
1336058030 Q * ncopa Quit: Leaving
1336058584 Q * Romster Remote host closed the connection
1336058824 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1336059999 Q * Bl4ckB1rD Quit: http://www.mibbit.com ajax IRC Client
1336061112 J * bonbons ~bonbons@2001:960:7ab:0:9dd:d380:e2d0:225c
1336061994 Q * bergerx Ping timeout: 480 seconds
1336063191 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com
1336063234 Q * BenG 
1336063749 Q * derjohn_mob Ping timeout: 480 seconds
1336066836 N * Bertl_zZ Bertl
1336066839 M * Bertl back now ...
1336067012 J * fzylogic ~fzylogic@69.170.166.146
1336067049 Q * fzylogic 
1336067053 J * fzylogic ~fzylogic@69.170.166.146
1336069987 Q * dowdle 
1336070235 J * dowdle ~dowdle@scott.coe.montana.edu
1336070238 J * ghislain1 ~AQUEOS@adsl1.aqueos.com
1336070533 Q * ghislain Ping timeout: 480 seconds
1336072227 J * hijacker ~hijacker@cable-84-43-134-121.mnet.bg
1336073487 Q * hijacker Quit: Leaving
1336078004 Q * clopez Ping timeout: 480 seconds
1336080027 Q * cuba33ci Read error: Connection reset by peer
1336080117 J * cuba33ci ~cuba33ci@114-36-227-97.dynamic.hinet.net
1336081576 Q * bonbons Quit: Leaving
1336082306 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1336082910 Q * Alex[fob] Ping timeout: 480 seconds
1336083435 J * clopez ~clopez@44.18.165.83.dynamic.mundo-r.com
1336084197 Q * fisted_ Read error: Operation timed out
1336085848 J * fisted ~fisted@xdsl-87-78-12-17.netcologne.de
1336087197 J * fisted_ ~fisted@xdsl-87-78-185-251.netcologne.de
1336087398 Q * fisted Ping timeout: 480 seconds
1336087864 Q * geb Ping timeout: 480 seconds
1336089299 Q * PowerKe Ping timeout: 480 seconds