xen - the ultimate setup.... legalabbis nekunk

A config nagyjabol ugy nez ki, hogy

gateway1                                     gateway2
   |						|
   |						|
   |						|
   +-----------------+     +--------------------+
                     |     |
	+------------+-----+------------+
        |            |     |		|
	|	    eth0  eth1		|
	|				|         
	|	XEN main server		|         
	|				|         
	+-------------------------------+

Tehat a xen server kapcsolodik 1-1 gatewayhez 1-1 interfacel. Ahhoz, hogy a legkevesebb ipcimet hasznaljuk de megse vesszuk el a lehetoseget, hogy az egyik gatewayt lehessen kikapcsolni ezert az eth0 es az eth1 interfacet bondoltam (primary,backup modeban) az ifenslave-el.

A kovetkezo problema ugye default gateway. Nem akartam HSRP/VRRP/GBLP-t futtatni a gatewayeken, mert lesz nekik eleg bajuk enelkul is. Szoval ugy dontottem, hogy quagga es eBGP. Szoval gateway1 es az XEN main server BGP-vel kommunikalnak es a XEN main server BGP-n keresztul kapja az alapertelmezett atjarot. Ugyanigy a gateway2-vel. A BGP majd eldonti melyiket fogja hasznalni alapbol. Ez annyira nem erdekel, mivel a halozati forgalom nem lesz eget rengeto.

A kovetkezo problema az a virtualis serverek configvaltoztatas nelkuli hordozhatosaga. Ami 2 dolgot jelenthet DHCP vagy ugyanaz az alhalo az osszes virtualis servernek. Ez utobbi kicsit vicces mivel 3 kulonbozo site van es mind3 ugyanazt az alhalot hirdeti akkor a blackholing veszelye egesz magas. Meg ekkora default gateway is kisse macerassa valik szoval kell valami routing protokoll, hogy hirdesse, hogy itt most melyik IPcim a default gateway. A DHCP-vel publikus ipcim kiosztasa megint csak nem megoldas, mivel akkor egy server mozgatasanal a dnseket valtoztatni kell, ami nem nagy problema csak macera amit szeretnenk elkerulni.

A megoldas amit talatam a kovetkezo. Loopback interfacek, ospf es egy kis nat. Felhuzunk egy bridge interface-t amire a virtualis hosztokat aggatjuk es azon hasznaljuk a 10.0.0.1/24 ip cimet. Valamint ezen futtatunk egy DHCP servert. Igy a virtualis hosztok majd dinamikusan kernek egy ipcimet. DHCP-vel megkapjak a default gatewayt is. A lo:1 interfacen beallitjuk nekik a publikus ipcimet. telepitunk egy quagga-t es ospf-el ravesszuk oket, hogy ezeket az interfaceket hirdessek. a XEN fo servert ravesszuk, hogy ami informaciot ospf-en keresztul megtanult hirdesse a bgp-be (termeszetesen a 10.0.0.0/24 kivetelevel). Igy a server mar elerheto a loopback interfaceken keresztul (SSH,HTTP serverek mar mennek).
A topologia ezidaig:

gateway1                                     gateway2
   |						|
   |						|
   |						|
   +-------------------+ +----------------------+
                       | |
	+--------------+-+--------------+
        |            	|               |
	|	      bond0    		|
	|				|         
	|	  XEN main server	|         
	|				|         
	|	      xenbr		|         
	+---------------+---------------+
			|
	+-------+-------+-------+-------+
	|	|	|	|	|
     +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
     | eth0| | eth0| | eth0| | eth0| | eth0| 
     |virt1| |virt2| |virt3| |virt4| |virt5| 
     +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
        +lo:1   +lo:1   +lo:1   +lo:1   +lo:1

Ami meg nem mukodik az a server internet elerese, mivel a server az eth0 ipcimet hasznalja forraskent. A megoldas egy kicsit dirty hack, (es varok jo otleteket, hogy hogy lehetne szebben megoldani) szoval

iptables -A POSTROUTING -j SAME -t nat --to xxx.xxx.xxx.xxx \! --proto 89

szoval minden csomag ami nem xxx.xxx.xxx.xxx-as forras ipcimmel rendelkezik vagy nem protocoll 89 (OSPF) natolva lesz es a forrasip a xxx.xxx.xxx.xxx-re le lesz cserelve. Igy szepen megy minden es a servernek mintha nem is lenne 10.0.0.0/24 subneten interface.

Ezzel meg is van oldva az IP cim hordozhatosaga.

A backup es clonozhatosagot pedig LVM snapshotinggal perobalkozok megoldani kicsit azt hiszem, hogy rendhagyo modon. Csinaltam egy nagy LVM particiot es ext3-ra formaztam. A XEN virtualis serverek ezen a particion kapnak 4gigas binaris fileokat. Ezeket a virtualis servereken tervezem LVM-be gyurni szoval extra hely hozzaadasa nem lesz problema.
A backup az nem lesz mas mint csinalni egy LVM snapshotot a XEN foserveren majd mountolni a snapshotot es megcsinalni a backupot az statikus filerendszeren.

Hat itt tartok most. Eddig megvan a routing resze. Most jon a backup tesztelese. A rendszer clonozas a teszt servereken meglepoen jol mukodott:
- LVM snapshot letrehozasa
- .img fileok masolasa
- a xen .conf file masolasa, hostname valtoztatasa
- xm create new.conf
es kesz.

Velemenyeket szivesen varok.