Search Results

Search found 2 results on 1 pages for 'scheintod'.

Page 1/1 | 1 

  • OpenVZ: Choosing right MySQL-Server depending on host

    - by Scheintod
    What I have: Two servers running Wheezy/OpenVZ with One MySQL container on each host master/master replicated (mysql1/mysql2) Replicated DNS on each host (dns1/dns2) different web-containers on each host but regulary backuped to the other. What I want: Each container should use the "local" MySQL-Server (the one which runs on the same hardware-node). I'd like to be able to move the web-containers between the to hosts. Each container should choose the MySQL-Server (semi) automatically. This scheme should continue working if one host is down. What I tried: Currently I'm keeping track on which container should run on which host by DNS entries which are queries by scripts e.g. for questions like: "Which container should be backuped on/to which host." For choosing the right MySQL server I have one extra entry like "mysql.container_abc" which resolves to either mysql1/mysql2. So in the applications in the container I can use "mysql.container_abc" for e.g. mysql_connect and if I want to move the container around I just need to change the dns. Now I notices one problem with this approach: Every mysql_connect generates one DNS query because the dns is not cached and this slows the request down unnecessarily. What I would like better: Some way of passing the information on which host we are running to the container and using it directly instead of using DNS. E.g. some way of setting a custom /etc/hosts entry in the container. Or any other great idea. Doesn't have to include DNS but shouldn't require to much special "magic" inside the container.

    Read the article

  • Why is Linux choosing the wrong source ip address

    - by Scheintod
    and what to do to let it choose the right one? This all happens inside an OpenVZ container: The Host is Debian/Wheezy with Redhat/OpenVZ Kernel: root@mycl2:~# uname -a Linux mycl2 2.6.32-openvz-042stab081.5-amd64 #1 SMP Mon Sep 30 16:40:27 MSK 2013 x86_64 GNU/Linux The container has two (virtual) network interfaces. One in public and one in private address-space: root@mycl2:~# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:127.0.0.2 P-t-P:127.0.0.2 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:475 errors:0 dropped:0 overruns:0 frame:0 TX packets:775 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:32059 (31.3 KiB) TX bytes:56309 (54.9 KiB) venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:80.123.123.29 P-t-P:80.123.123.29 Bcast:80.123.123.29 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 venet0:1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.0.1.29 P-t-P:10.0.1.29 Bcast:10.0.1.29 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 The route to the private network is set manually: root@mycl2:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 venet0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 venet0 Tring to ping others on the private network leads to the wrong source address been choosen: root@mycl2:~# ip route get 10.0.1.26 10.0.1.26 dev venet0 src 80.123.123.29 cache mtu 1500 advmss 1460 hoplimit 64 Why is this and what can I do about it? EDIT: If I create the route with (thanks to Joshua) ip route add 10.0.0.0/8 dev venet0 src 10.0.1.29 it is working. But according to man ip-route the src parameter should only set the source-ip if this route is chosen. But if this route is chosen then the source-ip would be that anyway.

    Read the article

1