Thanks Lennert. My issue isn't around the state of the VR as such, we've destroyed and brought back plenty with no issue, more so the impact it going down will have on my instances.
We're looking at consolidation ratios of 40 to 1 so Pods will have a large number of instances. We have been trying to work out the best way to use external DNS servers my main issue there has been that puppet requires the FQDN of the instance which they won't get until the external DNS servers respond appropriately which slows things down. We have been testing scripts to push DNS entries from the instances at start up which seems to work ok. How do you approach this problem? Nick On 11 November 2013 17:44, Lennert den Teuling <lenn...@pcextreme.nl> wrote: > > Op 12 november 2013 om 0:07 schreef Nick Wales <n...@nickwales.co.uk>: > > > > > > I have a couple issues with the current setup involving the virtual > router. > > > > 1. I'm not using the VR for port forwarding / VPN / routing or anything > > traffic related so it would seem to me to be relatively trivial to have a > > secondary virtual router that just provides DNS, userdata & metadata. > This > > would be sufficient for all my failover requirements. > > > > 2. It would also be useful to be able to set DNS options in a basic zone. > > Timeout, attempts etc. Timeout on linux is set to 5 seconds which is an > > eternity in case of failure. > > > > Are people comfortable with a single VR in a basic zone, and what > > mitigations can be put in place to avoid any fallout from failures? > > Hi Nick, > > When the VR is down, you could run into some issues especially when you are > recovering from hardware failure. In this case the instances that are down > will > not start until you fixed the router. This is quite logical cause they > need DHCP > for example. > > The router startup was quite slow in the past. We run about 400 VMs per > pod, and > you will not be very happy when it takes about 1 hour to reconfigure all > DHCP > entries. Luckily, the VR startup time has been improved a lot lately, and > for us > the same process takes about 15 minutes but still, it could be faster in > the > future. > > So when the VR doesn't boot you cannot boot your other VMs which could be > problematic even if it takes only 15 minutes. Because of this we are > planning to > move SSVMs (including the VR) to a seperate cluster so it doesn't run next > to > instances of our clients so both cannot (or shouldn't) be offline at the > same > time. > > Anyway, if you plan to run like up to 50 instances in a pod (using the > same VR), > this will won't be a problem for you cause VR startup time will probably be > acceptable. > > When you recreate the VR (which you should be able to do whenever you > want), it > will likely receive a new IP and you VMs need to renew their DHCP lease to > receive the new IP adres for DNS. This is why we have chosen not to use > the DNS > server of the VR. > > Hope this helps! > > Met vriendelijke groet / Kind regards, > > Lennert den Teuling > Tel direct: +31 (0)118 700 210 >
