Comments inline. On 12-Nov-2013, at 5:16 pm, Lennert den Teuling <lenn...@pcextreme.nl> wrote:
>> Op 12 november 2013 om 2:18 schreef Nick Wales <n...@nickwales.co.uk>: >> >> >> 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? > > If i understand you correctly, what you probably want is to directly update > your > (main) nameservers when a VM is started. I heard my colleague talking about > writing something for CloudStack which automatically add a records for the > hostname and reverse DNS when VMs are being deployed. This is something we are > currently looking into. Cloud-init would be a nice framework to standardise on as it already supports cloudstack meta-data services. One would have to write a customer DNS registration module and enable it in their template. Puppet etc would be a overkill for this task. > > If you systems (outside) CloudStack also use this nameservers (which is the > case > in our situation) the FQDN should be resolvable at once. Of course it could > take > some time for it to be available world-wide. > > It seems that there is already some code available which gets triggered at > these > events, but you still need to implement you own DNS infrastructure. AWS Route 53 would be a good choice. Looks like some already has added Router 53 support to cloud-init. https://github.com/lovelysystems/cloud-init/blob/master/cloudinit/CloudConfig/cc_dns.py > > Cheers, > Lennert > >> 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 >>> -- @shankerbalan M: +91 98860 60539 | O: +91 (80) 67935867 shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre, Bangalore - 560 055 CloudStack Bootcamp Training on 27/28 November, Bangalore http://www.shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
